moved from StoringFormValues
Static Form Options Definitions
When storing form values, TWiki bevahes this way (I'm mainly regarding TWiki %VARIABLES%: in form field values)
At least one application of mine currently breaks in Dakar due to this. I've
written a dirty patch once for
displaying
expanded values, but it always worked with TWikik storing the unexpanded values,
which made my internationalized application work.
Now I'm wondering what's the right thing. IMO values should be stored unexpanded. Example: in a internationalized application, I have a field in which the user must choose among some options, and those options are defined in
terms of
MAKETEXT's. So each user sees the options in its mother language. But once a user saves a new topic,
Dakar currently saves the value the user sees, and not the value that would show the correct translation depending
on the user language, i.e., other user, even if browsing in her own language, will see that value in the language
of the user who saved the topic.
So IMO all field values should be stored unexpanded, just as in Cairo.
Ideas?
--
AntonioTerceiro - 17 Jan 2006
There are probably two competing requirements. One is
DynamicFormOptionDefinitions where you need to expand variables such as
%SEARCH{}% in order go get selectors with options based on a search, which is a very useful feature for
TWikiApplications. On the other hand, there is your stated need to let variables survive an edit cycle.
I am wondering if there is a way to decouple the two requirements. Possibly by only evaluating the
%SEARCH{ with enclosed variables }% but no other top level variables?
I suggest to file a bug because the current spec breaks existing
TWikiApplications.
--
PeterThoeny - 17 Jan 2006
Maybe a solution could be adding an extra field to the form definition to differentiate dynamic form field definitions from static ones. Like this:
| *Name* | *Type* | *Size* | *Values* | *Tooltip* | *Dynamic?* |
| Field 1 | select | 1 | %SEARCH{ ... }% | bla bla | yes |
| Field 2 | checkbox | 1 | %MAKETEXT{...}%, %MAKETEXT{...}% | bla bla | no |
And in the case when that last field is not present, we could default to
yes, since (*I guess) I think that
DynamicFormOptionDefinitions
are the most common case in
TWikiApplications.
--
AntonioTerceiro - 18 Jan 2006