Item8671: Develop FlexFormPlugin to retrieve Form field selectable values.

Priority: Enhancement
Current State: Closed
Released In:
Target Release: n/a
Applies To: Extension
Component: FlexFormPlugin
Reported By: MartinCleaver
Waiting For:
Last Change By: KennethLavrsen
The following section appears in MultiTopicSavePlugin#AutoGeneratingOptions - it provides syntax to extract the default values supplied on a form from either a form definition topic or a topic that lists the options for the field. While this is convenient, it instead should be a core feature of Foswiki.

Here's the section

Auto generating the options list

Instead of manually defining the list of options in MULTITOPICSAVEINPUT you can load the list of options from the form definition topic. Assuming the values are defined in the form itself this is an example of setting a macro which you can then use later. In this example the form topic is called RequirementsForm and the field name is Platforms.

   * Set PLATFORMOPTIONS = %SEARCH{"\| *Platforms *\|" topic="RequirementsForm" regex="on" nonoise="on" multiple="on" format="$pattern(.*?\| *Platforms *\|[^\|]*\|[^\|]*\| *([^\|]*?) *\|.*)"}%


If the option values are defined in their own topic use instead this example

The topic called FieldName defines the values in a table like

Name Type Tooltip message
Open option Not yet resolved
Closed option Fixed and closed
Rejected option Not accepted and closed

The example below sets FIELDOPTIONS = Open, Closed, Rejected

   * Set FIELDOPTIONS = %SEARCH{ "^\|[^\|]*\| *option *\|" topic="FieldName" type="regex" multiple="on" nonoise="on" separator=", " format="$pattern(^\| *(.*?) *\|.*)" }%

   * Set TYPES = %SEARCH{"\| *Type *\|" topic="MultiTopicSaveTestForm" regex="on" nonoise="on" multiple="on" format="$pattern(.*?\| *Type *\|[^\|]*\|[^\|]*\| *([^\|]*?) *\|.*)"}%

The Foswiki core should provide a means to ask these for default values.

This isn't restricted to MultiTopicSavePlugin: every application writer needs this facility.

-- MartinCleaver - 05 Mar 2010

Also, the generic way should not be dependent on how the values are defined: this would allow a form author to change the definition to use a separate topic without it breaking the field value retrieval.

-- MartinCleaver - 06 Mar 2010

Are you raising this request to the engine or the MultiTopicSavePlugin?

-- KennethLavrsen - 06 Mar 2010

Martin has created the feature request MacroForRetrievingFieldDefaultValues.

-- ArthurClemens - 06 Mar 2010

MartinCleaver reads
[09:48am] MartinCleaver: oh - you've just released this!
[09:48am] MichaelDaum: grin
[09:50am] foswiki_irc1: I need the signature to be easy to use, the wiki is going to be used for fast information, and I need timestamps on each editing
[09:51am] MTempest: foswiki_irc1: Have you looked at CommentPlugin? It puts in timestamps and signatures automatically
[09:51am] MTempest: With CommentPlugin, you enter your comment in the text box and click the submit button. It is added to the topic with your name and a timestamp.
[09:52am] Babar: it doesn't have to be added to the topic 
[09:52am] • Babar is being pedantic, as usual
[09:52am] MTempest: ... or it can be more complicated if you want it to be more complicated 
[09:52am] • MartinCleaver is trying to figure out MichaelDaum 's plugin
[09:53am] MartinCleaver: MichaelDaum
[09:53am] • Babar did some SSP this morning...
[09:53am] • Babar wonders how he's still sane. Oh, of course, he never was!
[09:54am] • MartinCleaver wants a sync Google spreadsheet to Foswiki forms sync plugin
[09:54am] MichaelDaum: MartinCleaver, I know
[09:54am] MTempest: foswiki_irc1: There is also a way to force a new revision whenever a topic is saved. Depending on what you are trying to do, that might be useful.
[09:54am] MartinCleaver: so, how can I do this search with FlexFormPlugin?
[09:55am] foswiki_irc1: the topic will change with each edit, so it's not really comments I'm after
[09:55am] MartinCleaver: or do I have to adjust how I am using ?
[09:57am] MartinCleaver: I can appreciate that you must have iterated the field default values to implement your FlexFormPlugin, but it doesn't seem to expose them
[09:57am] MichaelDaum: MartinCleaver, this search is really no solution. The core already knows how to deal with formfield values. that is read them and generate an interface for it.
[09:57am] EvanghelosPapaio joined the chat room.
[09:57am] MichaelDaum: that's what %RENDERFOREDIT leverages to wiki apps level
[09:57am] MartinCleaver: y, I don't want to SEARCH
[09:58am] MartinCleaver: I want to say "give me the field values"
[09:58am] MartinCleaver: but I don't want the whole form rendered
[09:59am] MichaelDaum: %RENDERFOREDIT will always come via a DataForm definition of some formfield
[09:59am] MartinCleaver: is there a macro way to retrieve those default field values?
[10:00am] MartinCleaver: Have you used MultiTopicSavePlugin?
[10:00am] MichaelDaum: in which context do you need the field values
[10:00am] MichaelDaum: nope
[10:00am] MartinCleaver: ok. one sec.
[10:00am] MartinCleaver: Start at
[10:01am] MichaelDaum: y I know, skimmed over it briefly
[10:01am] MartinCleaver: Right, so it can be used to provide a grid mode for editing all records using a given form
[10:01am] MartinCleaver: See the  Type, Animal and Friend column?
[10:02am] MartinCleaver: These are inserted in the grid using: %MULTITOPICSAVEINPUT{"Type" type="radio" size="1" delay="1" web="$web" topic="$topic" value="$value" options="%TYPES%" editmode="%URLPARAM{"multiedit" default="off"}%" lockmode="on"}% | \
[10:02am] MTempest: foswiki_irc1: Since I'm not really sure what you are trying to achieve, I'm afraid I can't make more suggestions. I do hope you find what you are looking for 
[10:02am] MartinCleaver: Now see %TYPPES% is defined
[10:02am] MartinCleaver: %TYPES%, rather
[10:02am] MartinCleaver: with this:    * Set TYPES = %SEARCH{"\| *Type *\|" topic="MultiTopicSaveTestForm" regex="on" nonoise="on" multiple="on" format="$pattern(.*?\| *Type *\|[^\|]*\|[^\|]*\| *([^\|]*?) *\|.*)"}%
[10:02am] MartinCleaver: bluergh
[10:02am] MichaelDaum: ... which is outch
[10:02am] MartinCleaver: quite
[10:03am] MichaelDaum: Let's assume there's some kind of DataForm definition that specifies a Types formfield
[10:03am] MichaelDaum: as a radio box
[10:03am] MartinCleaver: especially as this SEARCH is dependent on whether the values come from on the form on a topic-for-values linked from the form
[10:03am] MichaelDaum: | Types | radio | 1 | value1, value2, ... | you know that thing
[10:04am] MartinCleaver: I usually use the other way, like:
[10:04am] MartinCleaver: | TypeUsed | radio |
[10:04am] MartinCleaver: and define that topic
[10:04am] MichaelDaum: ok
[10:04am] MartinCleaver: TypeUsed as a SEARCH
[10:04am] MartinCleaver: that pulls from a further set
[10:05am] MichaelDaum: now %RENDERFOREDIT{field="TypeUsed" form="FormDefinition" }% will render the radio box interface
[10:05am] MichaelDaum: with all values in it
[10:05am] MartinCleaver: ah
[10:05am] MartinCleaver: So, just the field, not the entire form
[10:05am] MichaelDaum: or %RENDERFOREDIT{"topic" ....}% to get the current values from that topic
[10:06am] MichaelDaum: it renders as those fields that you like to
[10:06am] MichaelDaum: for instance
[10:06am] MartinCleaver: So I could embed the RENDERFOREDIT inside the Form used instead of a line %MULTITOPICSAVEINPUT{"Type" type="radio" ...}%
[10:06am] MichaelDaum: %RENDERFOREDIT{"DataTopic"}% will render an interface for all of the form
[10:06am] MichaelDaum: correct
[10:06am] MartinCleaver: ok, that I missed
[10:07am] MartinCleaver: I wonder how nicely the two mechanisms will blend
[10:07am] MartinCleaver: I'll try it
[10:07am] MichaelDaum: there have been other extensions in that area which try to ease rendering edit interfaces for DataForms
[10:07am] MichaelDaum: but they seem to ... reinvent the wheel already there in the core
[10:08am] MartinCleaver: still, the core still needs a way to say give me the values. There isn't a way in the core to get those values is there?
[10:08am] MichaelDaum: in the core? no.
[10:09am] MartinCleaver: So the data-retrieval method you've built into your new plugin could be located into the core
[10:09am] MichaelDaum: the core does deal with formfield values as part of the From class
[10:09am] MichaelDaum: ... which is quite pluggable
[10:09am] MichaelDaum: in itself
[10:10am] MartinCleaver: the core  needs to expose them - I can imagine that you might have had make assumptions about implementation in order for your new plugin to get those data elements
[10:10am] MartinCleaver: ?
[10:11am] MichaelDaum: not really. It fetches the Form definition - the class - and uses its renderForEdit() api
[10:11am] MartinCleaver: is Form part of the Func:: interface?
[10:12am] • MartinCleaver tries Padre
[10:12am] MichaelDaum: no. this is called more OO-like: my $formDef = new Foswiki::Form($session, $web, $topic);
[10:14am] MartinCleaver: are plugins "allowed" to use foswiki internal classes?
[10:14am] MartinCleaver: I agree its the right way, btw
[10:14am] Babar: allowed, yes, but it might break without warning 
[10:14am] MichaelDaum: can't say. I use what I get and stretch it til it breaks 
[10:15am] MartinCleaver:
[10:15am] MartinCleaver: better that than duplicate code
[10:16am] • MartinCleaver is reading FlexPlugin code
[10:17am] MartinCleaver: ok - I will have to continue this later
[10:17am] MartinCleaver: thanks MichaelDaum
[10:17am] MichaelDaum: yw, hope it helps solve your prob
[10:19am] MartinCleaver: Looks like    my $fieldAllowedValues = $field->{value}; (L279) ?
[10:20am] MartinCleaver: looks like Foswiki has already built an internal model (rather than check the two places manually as per Lavr 's SEARCH)
[10:22am] MartinCleaver: I'm somewhat concerned about mixing RENDERFOREDIT and MULTISAVEINPUT
[10:22am] MartinCleaver: actually - they do practically the same thing, these two
[10:24am] • MartinCleaver wanders off

-- MartinCleaver - 08 Mar 2010

Re-assigning to core

-- KennethLavrsen - 08 Mar 2010

The title of this task is a bit misleading. Allowed values for a formfield are always part of the DataForm definition. There are more properties of a form definition that are worth querying besides the list of allowed values for one field. That's why we should try to make the form accessible as an object which then serves as an interface to the names of all formfields, a formfield's type, attributes, current value, default value as well as all allowed values.

Current plugin solutions suffer from using quasi non-official apis to get access to the form definition. As a first step things would be a lot easier if we had a Foswiki::Func::getFormDefinition() call which encapsulates a new Foswiki::Form() call. Once you've got your hands on a form object, extracting the wanted information using core means ( which are already there ready to be used as is ) is a no brainer.

-- MichaelDaum - 09 Mar 2010

Why pass a form object if you need to use the Form API to operate on it? Instead of using Func, perhaps we need to formalize the public methods of Form?

-- ArthurClemens - 09 Mar 2010

You can now do this with FlexFormPlugin:

%RENDERFORDISPLAY{ form="NameOfForm" field="FromRole" format="!$title=$options" optionsSeparator="," }%

This will ask Foswiki for the values provided on the schema.

-- MartinCleaver - 11 Mar 2010

Will have to cleanup this as there already was means to get all allowed values.

This is now
  fields="Field1, Field2, Field3"
  format="   * allowed values for $title are $values, default is $default$n"

-- MichaelDaum - 12 Mar 2010

Implemented as plugin.

-- MichaelDaum - 24 Mar 2010

Changed the headline and changed bug item to cover FlexFormPlugin

The original problem was not solved just because some plugin implements the feature.

But the original problem requires a feature proposal anyway. We cannot do such enhancement on bug item

-- KennethLavrsen - 24 Mar 2010
Topic revision: r20 - 24 Mar 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy