create new tag
, view all tags
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)

Version Stores fields Shows for editing as
CairoRelease unexpanded, for all types of fields unexpanded for text types and select. Expanded labels for checkboxes and radios
DakarRelease unexpanded only for text, expanded for others unexpanded for text types. Expanded labels for checkboxes, radios and select

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.


-- 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

Topic revision: r1 - 2006-01-18 - AntonioTerceiro
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.