Need Spec for Form Value Initialization

For the cairo release, we had agreed on the following algorithm:

The order of priority of field initialization should be as follows: For a given form field

• If a value was passed in by a corresponding query parameter, that value should be taken, else
• If the existing topic has a corresponding field value, that value should be taken, else
• If there is no existing topic and there is a templatetopic and there is a corresponding field value, that value should be taken, else
• If there is an initialization value defined in the formtemplate, that value should be taken, else
• The field value should be empty.

There is some question as to what should happen to TWikiVariables.

• Of course the text is taken literally (i.e., variables are not expanded) when it is in the existing form of the topic being edited
• However, variables in values copied from a form are expanded, as well as when values are taken from a template topic.

The latter serves to, e.g., create timestamps when expanding %SERVERTIME{"$day $mon $year $hour:$min"}%. But there is currently now way of getting a variable unexpanded, so that it could be expanded later, from the form or template. (Note that TWiki:Plugins.EditTablePlugin allows the use of escapes, such as $percnt, $dollar, or $nop to prevent expansion.)

Secondly, it is maybe somewhat unintuitive that when text is taken from a template it is expanded.

Note further that a template is not used when an existing topic is edited, even if there is no form attached to that topic.

I need two clarifications:

1. Should the template topic be ignored whenever a text is given, even if there is no form attached to text.
2. Should variables embedded in values copied from the formtemplate be expanded, and if so, should there be a way of protecting the variables from expansion (as in EditTablePlugin)?

I am further somewhat unclear on the "special handling for untitled labels" that is done in Form.pm. The values there are never taken from the topic, but always from the form. (I think they can never be in the topic?)

-- Contributors: ThomasWeigert - 02 Oct 2006

Discussion

I have a patch that implements the strategy from EditTablePlugin. See Bugs:Item2905.

-- ThomasWeigert - 03 Oct 2006

This request deserves feedback. I can see from Bugs:Item2905 that even CC has trouble getting the clear picture as to what would be right or wrong. And I for sure would like to see some examples.

Thomas - can you perhaps provide an example set of topics that illustrate the problem.

Are there any compatibility issues related to your proposal or is it goind to how things worked in Cairo?

Can you propose a short clear spec? Is the proposed spec the intro from Bugs:Item2905?

From what I can sense it seems you have something right here which will be accepted - once people understand it. And you already have the patch for it I (available for download on Bugs:Item2905). If you propose a spec and noone challenge it - it is automatically accepted after 14 days per our process. And this feedback is not a challenge. Just trying to trigger some help for Thomas.

-- KennethLavrsen - 05 Oct 2006

The proposed spec is:

• Variables in the initial values of a form definition get expanded when form values are initialized from the form definition. The escape characters $quot, $percnt, $dollar, and $nop can be used to prevent expansion.

Note that when initial values are taken from templates or form fields in the topic, then contained variables are not expanded.

This proposed spec clarification is consistent with the explicit spec in EditTablePlugin.

-- ThomasWeigert - 06 Oct 2006

SteffenPoulsen. You had the action from EdinburghReleaseMeeting2006x10x16 to review if the proposed spec has negative impact. Unless we hear something against within a few days - I will flip this to accepted. I will give Steffen until 29 OCt 2006 (ask for more time if you need it).

-- KennethLavrsen - 23 Oct 2006

I have emailed Steffen here on the 29th in the evening.

-- KennethLavrsen - 28 Oct 2006

Thanks, Kenneth, and sorry for holding this one back.

I don't see any problems in this spec and the patch at Bugs:Item2905 (at least in line with how we are using forms in our place). The prevention of expansion is indeed very useful.

I am usure if there is a full patch available for all the functionality suggested here so real life testing might show up something - but let's take it from there?

-- SteffenPoulsen - 29 Oct 2006

Thanks Steffen. So Thomas. All green lights.

-- KennethLavrsen - 30 Oct 2006

Done.

-- ThomasWeigert - 30 Oct 2006