In TWiki 4.0.2,
is told to always initialize fields that were not given values in the query. The effect is that values will never be taken from the form, as
does this only when the field value is undefined (to distinguish from empty field values). In TWiki 4.0.4, there is not even a conditionalization left, but the code always acts as if
was passed earlier.
This is inconsistent with the past, I think.
In Cairo, 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 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.
Can anyone comment on why this changed? (The conditionalization has also been removed from
I will fix otherwise....
See discussions from Cairo days also in FormValuesPassedInURLRequireText
Marked as requirement as it involves a change to past behavior...
Please be very, very careful here. This was the subject of a bug which I can't find now, which caused much agony.
The spec of
is that it gets values from the query; it must not
apply default values from the form.
works by populating the meta from the topic, and then overriding them with the contents of the query. Then it calls
which populates any field values that are missing from the defaults in the form definition. Since the initial meta comes from the template topic, that means that the initialisation order you describe above is applied.
similarly populates from the meta, then the query, the the form.
If you think that this is not
the case, you must
provide a unit test before proceeding with any code changes. The code in this area is mostly inherited from Cairo and is extremely confusing and fragile, so I really, really, don't want to risk any changes without a safety net. There are a number of annotations in the code highlighting where I think there are structural problems.
Discarded pending a testcase that demonstrates a problem with the existing code.
Test case is in SVN as
The other item I was concerned about was fixed in ~twiki4 relative to 4.0.2
The testcase reveals that there is a problem when TWikiVariables
are passed into the form. The spec is
- If a TWikiVariables is passed, it is expanded and the expanded value is written into the form
- If a TWikiVariables is passed protected from expansion, the tag is written in the form.
In other words, TWikiVariables
and <nop> are expanded. -- TW
I have been searching all over the doco to find where I got the above from. The closest I can come is the documentation in TWiki:Plugins.EditTablePlugin
, which states
- "By default, variables in the initial values (of text input field and of label fields get expanded when a new row is added. This can be used for example to add a timestamp to a label. You can escape characters if you do not want that" and it explains
$, and == as possible escapes. (Not <nop> as I wrote in the test case, so I need to fix that.)
We need to clarify the spec here...
Basically, if the initial value is taken from a form, it is expanded. If the initial value is taken from the template, or the existing topic, then it is not expanded. (The latter is reflected by
failing on the
field; I believe they behave per spec so I will change the test case.)
I think the best thing would be to implement what is advertised in TWiki:Plugins.EditTablePlugin
, i.e., have the well-known TWiki escapes.
We could also not expand the values when received from Forms, but that would change the existing behavior that some may rely upon, e.g., to insert timestamps when attaching a form.
For sure that is not documented well enough. I bet some users are surprised to find that (i) there timestamps in a template are not expanded, or that their %ATTACHURL% in the form are expanded. -- TW
Patch attached to implement the doco from TWiki:Plugins.EditTablePlugin
. Testcase passes. -- TW
Agreed, the doc is weak, and always has been.
w.r.t your attached patch; why not just call
Didn't know about this function... -- TW
Feedback on the spec clarification would be appreciated... -- TW
On escapes; I am all in favour of standardising on the escapes in
- it's why I added that function.
w.r.t expansions in initial form fields, I really don't feel qualified to comment. In a situation like this my instinct is to ask "Thomas, is this right.....". What you describe sounds
about right. It doesn't surprise me at all that this isn't documented; AFAICT a lot of this code was grown, rather than being designed, and doc written after
the code (always a bad idea) so it tends to reflect what the implementor thought was needed at the time.
I am now using
. I think this function could do with the ability to apply
and then could be used even wider... --TW
Implemented, documented, and wrote unit test. -- TW
Moved discussion of making test cases more resilient to Item3144
Changed headline for release note KJL