Feature Proposal: We need to centralise into core the means to retrieve field default values

Motivation

In MultiTopicSavePlugin you can edit the data forms of many topics at the same time. When you edit you may need to provide a form with checkboxes where the values for the options should come from the field definition and those field definitions options are defined either:

• from the form or
• from the separate topic

Sometimes option values are stored in the Form and sometimes they are stored as a table in a topic linked to from the Form

In Tasks.Item8671 Kenneth provides two SEARCHs to retrieve such values, but which SEARCH the page author needs to use depends on how the form are using was defined.

But I don't want to write yet another search for every field value - I should be able to ask Foswiki for a given field's default values. Further, it should hide the detail of whether the values are on the form or in separate topics.

ArthurClemens posed that there might already be a plugin to do this, but didn't know which. I'd suggest the mechanism belongs in core anyway.

Description and Documentation

%FIELDDEFAULTS{"Web.Form:field", format="$field,"}

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: MartinCleaver - 06 Mar 2010

Discussion

I wonder if this should be considered as a part of CleanerSyntaxForMetaDataAccess

-- PaulHarvey - 07 Mar 2010

Implemented as plugin: FlexFormPlugin.

-- MichaelDaum - 08 Mar 2010

FlexFormPlugin uses non-API such as my $form = new Foswiki::Form($session, $theFormWeb, $theForm);

This means that you cannot be sure this plugin works each time you upgrade Foswiki.

But I understand why Michael does it like this because the current API does not remotely give a plugin author access to this.

I could have added the feature to Extensions/MultiTopicSavePlugin but I decided not to because I want my plugins to be clean and pure publiced API.

Writing the code that fetches the values from the form means copying half the form code from core and that makes no sense either.

We really need a core API so both MultiTopicSavePlugin and FlexFormPlugin can get proper access.

One simple way would be to declare the Form.pm API like we have done with Meta.pm.

-- KennethLavrsen - 08 Mar 2010

I actually think exposing Form.pm would be a great idea, but we still need to solve some problems with the mangling of newlines which might slightly change the way some of it works Tasks.Item5812 Tasks.Item5489

-- PaulHarvey - 08 Mar 2010

Two observations:

1. Field defaults are fickle, when they are built from a SEARCH. What context should the search be run in?
2. Fields have current values as well as defaults; this proposal is incomplete without considering that.

I don't think this overlaps CleanerSyntaxForMetaDataAccess because the values in question are not retrievable from the static data store (due to a combination of their being generatable from SEARCH and their being embedded in an informal schema in topic text anyway). However I wouldn't rush into this; it will take some careful thinking to come up with an integrated solution.

-- CrawfordCurrie - 10 Mar 2010

Ok - my needs have been met with the latest changes to Michael Daum's FlexFormPlugin.

I can now write:

%RENDERFORDISPLAY{
  form="ValueTransactionForm" field="FromRole" format="$values" valueseparator=","
}%

And it gives me the field values permitted. Michael also implemented the ability to retrieve the value currently selected.

So, I can write:

   * Set FROMROLES = %RENDERFORDISPLAY{ form="ValueTransactionForm" field="FromRole" format="$values" valueseparator=","}%
   * Set TOROLES = %RENDERFORDISPLAY{ form="ValueTransactionForm" field="ToRole" format="$values" valueseparator=","}%

And then, using MultiTopicSavePlugin

%MULTITOPICSAVEINPUT{"FromRole" type="checkbox" size="20" web="$web" options="%FROMROLES%" topic="$topic" value="$value" delay="1" editmode="%URLPARAM{"multiedit" default="off"}%" lockmode="on"}% | \
%MULTITOPICSAVEINPUT{"ToRole" type="checkbox" size="20" web="$web" options="%TOROLES%" topic="$topic" value="$value" delay="1" editmode="%URLPARAM{"multiedit" default="off"}%" lockmode="on"}% | \

Gosh. It's readable

Thanks to MichaelDaum and KennethLavrsen

-- MartinCleaver - 12 Mar 2010

You are welcome Martin.

I still believe this plugin solution is not correct.

In Foswiki applications we still often need to list the possible options from a form definition topic. Typically to make a html form to create a new topic.

And I still have no other way to do it than a formatted search on the form topic. It would be nice with a core feature for this.

And in Plugin land, we still have no API to get these values. FlexFormPlugin is not API compliant. You cannot rely on this plugin to work when you upgrade Foswiki. But writing a plugin like FlexFormPlugin without calling non-API requires copying around 1000 lines of code from core.

We need an API way to get the basic properties of form fields. Besides the current value we need the properties like type, size and list of options.

With this I could extend the MultiTopicSavePlugin so you could write

%MULTITOPICSAVEINPUT{"FromRole" type="checkbox" size="20" web="$web" options="$options" topic="$topic" value="$value" delay="1" editmode="%URLPARAM{"multiedit" default="off"}%" lockmode="on"}% | \
%MULTITOPICSAVEINPUT{"ToRole" type="checkbox" size="20" web="$web" options="$options" topic="$topic" value="$value" delay="1" editmode="%URLPARAM{"multiedit" default="off"}%" lockmode="on"}% | \

I do not feel like using non-API in my plugins.

In a Macro context getting the options in a format I can specify is what we need.

-- KennethLavrsen - 13 Mar 2010

Meanwhile, FlexFormPlugin has become an essential building for a couple of clients. Therefore, it won't be abandoned. It is in use on stable and trunk on a daily base.

That's more trustworthy than any use of non-core APIs.

Rest assured that this plugin will work when you upgrade. Any other claim is FUD.

Looking forward to use some kind of core API like Foswiki::Func::getForm().

-- MichaelDaum - 14 Mar 2010