• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7700 for generic doc work for TWiki-6.0.2. Use View topic Item7703 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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

  1. If a value was passed in by a corresponding query parameter, that value should be taken, else
  2. If there is a templatetopic and there is a corresponding field value, that value should be taken, else
  3. If there is an initialization value defined in the formtemplate, that value should be taken, else
  4. 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

ItemTemplate
Summary Form initialization with defaults not working.
ReportedBy TWiki:Main.ThomasWeigert
Codebase ~twiki4
SVN Range TWiki-4.1, Sat, 23 Sep 2006, build 11571
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 11631 11632 11633 11636 11637 11638 11640 11851 11950 11951 11952
TargetRelease minor
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch Form.pm.patch r1 manage 0.6 K 2006-10-01 - 18:36 ThomasWeigert Patch.
Edit | Attach | Watch | Print version | History: r35 < r34 < r33 < r32 < r31 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r35 - 2007-01-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback