In TWiki 4.0.2,
Form.pm
,
TWiki::Form::getFieldValuesFromQuery
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
TWiki::Form::renderForEdit
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
1
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
TWiki::Form::renderForEdit
. Why?)
I will fix otherwise....
See discussions from Cairo days also in
FormValuesPassedInURLRequireText and
ConsistentDefaultValuesForForms ...
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
getFieldValuesFromQuery
is that it gets values from the query; it must
not apply default values from the form.
edit
works by populating the meta from the topic, and then overriding them with the contents of the query. Then it calls
renderForEdit
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.
save
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.
CC
Test case is in SVN as
test/unit/InitFormTests.pm
.
The other item I was concerned about was fixed in ~twiki4 relative to 4.0.2
--
TW
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
test_edit4
,
test_edit3
,
test_edit5
,
test_edit6
, and
test_edit8
failing on the
History1
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
TWiki::expandStandardEscapes()
?
CC
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
TWiki::expandStandardEscapes()
- 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.
CC
I am now using
TWiki::expandStandardEscapes()
. I think this function could do with the ability to apply
$TranslationToken
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 --
TW
Changed headline for release note
KJL
4.1.0 released
KJL