create new tag
, view all tags

Topic Summary

This topic explores how to allow use of a SEARCH to dynamically define TWikiForms options.


TWikiForms allow you to provde a list of values for a form field using either 1) a comma-delineated list in the WebForm definition, or 2) a table defined in a separate topic. In many cases, it would be very useful to be able to create this list dynamically, using a FormattedSearch. However, TWiki does not currently allow defining the field values using a search.

Use case: I am creating a bug tracking system in TWiki and have defined a WebForm for listing ReleaseNames. Now I want to create another WebForm for listing BugReports that includes a field for selecting the pertinant ReleaseName. Currently, I would have to manually create the list of ReleaseNames. It would be nice to be able to define a search that automatically list of the ReleaseNames.


Allow use of FormattedSearch to define a list of values for use in a TWikiForms field.

Some complications of implementing this solution were discussed in TWikiFormsDontExpandVariables and HandleCommonTagsInFormDef


As discussed further below, this proposal has been implemented as an AddOnPackage for Cairo (FormsAddOn). It has now been ported to Dakar and is proposed to be integrated. FormsAddOn gives the details. (Note that FormsAddOn also gives the ability to define alternate layout for forms, which goes beyond DynamicFormOptionDefinitions, and is thus not yet considered. The plan is to generate that as a plugin for arbitrary form rendering, provided a suitable API extension is adopted.)


Code checked into SVN as 4128, 4155, 4161. Handling for untitled label fields is at 4162. After reworking the templates for ClassicSkin, need to add templates for PatternSkin 4195.


Documentation changes to TWikiForms are attached.

Original post

I have a set of pages named ReleaseXXX (autogenerated number so the pagename is a unique key) that contain only form data. To create a BugXXX entry I want to have a list of ReleaseNames (a field in ReleaseXXX) which then get stored as the appropriate ReleasseXXX topic.

first step

- populate the select FormField with a list of ReleaseNames. This i acheived by creating a page containing a SEARCh that is formated as the appropriate table. Then I modified the Forms definition code to render the SEARCH.

turns out to be a single line in getFormDef, with no extra cpu cycles unless you point your form to a SEARCH based Field definition.

   $text =~ s/%SEARCH{(.*?)}%/&TWiki::handleSearchWeb($1)/geo;

just before the line (in Form.pm)

   @posValues = getPossibleFieldValues( $text );

Field Aliases and other refinements

now comes the harder part... I want to display one thing, but store another... I haven't figured out a good way to do this. (I am thinking that there can be a Metadata value and a metadata text..)

Misc. supporting work

When I originally made the BugsWikiSystem I created a createBug Script that was a copy of the edit script with a unique Id Number generator to get BugXXX as a topic name. This I am now making more generic.

Secondly, I added a HIDETEXTAREA tag that is used in the view and edit rendering to remove the html textarea (I think i had to hard code it for the version of the TigerSkin that we use). It owuld be good to be able to hide the textarea more generically (so its not template implementation dependant)

-- SvenDowideit - 29 Nov 2002


Peter - can you please consider putting this in the code - I am trying to clean up my twiki code, and I think this is a worthwhile addition

-- SvenDowideit - 07 Mar 2003

Yes, that makes sense and it does not break existing content.

-- PeterThoeny - 07 Mar 2003

Back after 30 minutes: My first attempt with your code failes for two reasons:

  • Your code assumes that the select items are defined in another topic. It should be generic enough to support also select, checkbox and radio defined in one form. See "Defining a Form in One Topic" in TWikiForms.
  • The FormattedSearch always generates new lines between items, which breaks the form definition display. That means, we need a new separator=", " switch in %SEARCH%

-- PeterThoeny - 07 Mar 2003

mmm i can understand the first issue - i define my forms with seperate topics for each option set in a different topic. can you clrify for me - is the second issue related to the first, or is there yet another forms thing i know nothing about ??

-- SvenDowideit - 07 Mar 2003

The second issue is an artefact of the first, e.g. when you define a form in one topic only.

-- PeterThoeny - 07 Mar 2003

okely - i'll get back with another attempt in a few days (hopefully)

about the second - whats wrong with

Diff select 1 CairoDakarRegistrationDifference, DakarDiffsInFormHandling, DiffAttachments, DiffAutoArchive, DiffDoesNotAuthenticate, DiffRawRendering, DiffShouldSupportByWord, DiffShouldSuppressTopicInfoMetaData, DifferencesBetweenRevisionsBroken, DifferentSecurityLevelsInSameTWikiInstallation, DiffingWithVersionAttribution, DiffsFunctionDoesNotAuthenticateProperly, DiffsHardToRecognize, DiffsInNotifyEmail, DiffsRevertsToOneError, DiffsShouldShowEntireTableRow, EmptyDiffsOnTWikiDotOrg, HandlingCairoDakarPluginDifferences, HardwiredRDiffColours, HtmlAnchorsOnRdiffSequentialOutput, HumbleDiffs, IncludeFromDifferentCharsetSite, InvalidHtmlFixRdiff, KeepRcsAndTxtInDifferentPlaces, LastDiffFeature, LinksDontDifferentiateIdenticalHeadings, NoContextRdiffFix, PreviewandViewRenderDifferently, RdiffCgiScript, RdiffErrorNoSuchFileOrDirectory, RdiffIgnoresPermissions, RdiffMissingSigs, RdiffNotAuthWhenViewAuthUsed, RdiffShouldShowContext, RdiffauthCgiScript, RemoveDiffs, RestoreFromDiffsView, SecurityAlertTWiki4RdiffPreviewAccess, SelectableDiffs, SolarisBinaryFileDifferError, SupportDifferentSkinsForDifferentBrowsers, TWikiFormsDiffRendering, TaintBugInDiffs, TestEnvPerlDiffs, UnifiedDiffOutput, UsingRCSDirectoryResultsInInitalVersionAndBrokenDiff, VariableDifferencesInTemplates, WhatDifferenceBetweenATopicAndAWeb, WordDiff blah

-- SvenDowideit - 07 Mar 2003

There is a new line between each item, taking apart the table. (Added table for demonstration)

-- PeterThoeny - 07 Mar 2003

what if we add a nolinefeed parameter to SEARCH?

Index: Form.pm
RCS file: /cvsroot/twiki/twiki/lib/TWiki/Form.pm,v
retrieving revision 1.34
diff -u -r1.34 Form.pm
--- Form.pm     4 Mar 2003 05:22:42 -0000       1.34
+++ Form.pm     10 Mar 2003 00:44:07 -0000
@@ -58,6 +58,8 @@
                 $size = 1 if( ! $size );
+#SVEN - add processing of SEARCHES for Lists
+                $vals =~ s/%SEARCH{(.*?)}%/&TWiki::handleSearchWeb($1)/geo;
                 $vals =~ s/^\s*//go;
                 $vals =~ s/\s*$//go;
                 $vals =~ s/"//go; # " would break parsing off META variables
@@ -151,6 +153,8 @@
         if( ( ! @posValues ) && &TWiki::Store::topicExists( $webName, $name ) ) {
             my( $meta, $text ) = &TWiki::Store::readTopic( $webName, $name );
+#SVEN - add processing of SEARCHES for Lists
+            $text =~ s/%SEARCH{(.*?)}%/&TWiki::handleSearchWeb($1)/geo;
             @posValues = getPossibleFieldValues( $text );
             if( ! $type ) {
                 $type = "select";  #FIXME keep?
Index: Search.pm
RCS file: /cvsroot/twiki/twiki/lib/TWiki/Search.pm,v
retrieving revision 1.47
diff -u -r1.47 Search.pm
--- Search.pm   5 Jan 2003 01:53:57 -0000       1.47
+++ Search.pm   10 Mar 2003 00:44:08 -0000
@@ -61,7 +61,7 @@
          $theRegex, $theLimit, $revSort, $caseSensitive, $noSummary,
          $noSearch, $noHeader, $noTotal, $doBookView, $doRenameView,
          $doShowLock, $noEmpty, $theTemplate, $theHeader, $theFormat,
-         @junk ) = @_;
+         $noLineFeed, @junk ) = @_;
     ##TWiki::writeDebug "Search locale is $TWiki::siteLocale";
@@ -101,6 +101,7 @@
             # the web processing loop filters for valid web names, so don't do it here.
             if( $web =~ /^(all|on)$/i  ) {
+#SVEN - this should be a call to &TWiki::Store::getWebList
                 # get list of all webs by scanning $dataDir
                 opendir DIR, $TWiki::dataDir;
                 my @tmpList = readdir(DIR);
@@ -522,7 +523,11 @@
             if( $theFormat ) {
                 $tempVal = $theFormat;
+if ( $noLineFeed ) {
+                $tempVal =~ s/([^\n])$/$1/gos;       # cut last trailing new line
+} else {
                 $tempVal =~ s/([^\n])$/$1\n/gos;       # cut last trailing new line
                 $tempVal =~ s/\$n\(\)/\n/gos;          # expand "$n()" to new line
                # TODO: i18n fix
                 $tempVal =~ s/\$n([^a-zA-Z])/\n$1/gos; # expand "$n" to new line

However I have thought of another thing we should try to figure out. how can I change the source topic for a value without changeing the name of that column? I am changing my Forms from hard coded values to a SEARCH topic in a different web (because the value list is used in a number of forms) but changing the name of the column breaks older searches.

can we use INCLUDE in the values field? (except linefeeds kill us there too)

-- SvenDowideit - 10 Mar 2003

The patch mentioned in TWikiFormsDiffRendering might be what you want. It allows you to write sth. like [[CoreTeam][Approve by]] as field definition, i.e. the form says 'Approve by', but the actual definitions comes from 'CoreTeam'.

Patch of getFormDefinition() against AthensRelease:

Index: Form.pm
RCS file: /var/cvs/twiki/lib/TWiki/Form.pm,v
retrieving revision 1.1
retrieving revision 1.3
diff -c -r1.1 -r1.3
*** Form.pm     2002/06/19 13:53:16     1.1
--- Form.pm     2002/12/20 15:36:00     1.3
*** 44,49 ****
--- 44,53 ----
                $title =~ s/^\s*//go;
                $title =~ s/\s*$//go;
                my $name = _cleanField( $title );
+               if( $title =~ /\[\[(.+)\]\[(.+)\]\]/ )  { # use common defining
+                   $name = _cleanField( $1 );            # topics with diff.
+                   $title = $2;                          # field titles
+               }
                $type = lc $type;
                $type =~ s/[^a-z+]//go;
                $type = "text" if( ! $type );
Caveat: TWiki uses the defining topic name as key. Therefore, you can't write:
  1. [[DevTeam][Owner]]
  2. [[DevTeam][Tester]]
  3. [[DevTeam][Reviewer]]
i.e. reuse the same definition topic multiple times in one form

-- PeterKlausner - 11 Mar 2003

Peter, yes!!! that is marvelous. its shown up 2 bugs in the form system (as there is an assumption that the meta name and title are equivalent) so here is the diffs for that too smile

Index: Form.pm
RCS file: /cvsroot/twiki/twiki/lib/TWiki/Form.pm,v
retrieving revision 1.34
diff -r1.34 Form.pm
> #PeterKlausner's [[CoreTeam][Approve by]] as field definition
>                if( $title =~ /\[\[(.+)\]\[(.+)\]\]/ )  { # use common defining
>                    $name = _cleanField( $1 );            # topics with diff.
>                    $title = $2;                          # field titles
>                }
<         if( ( ! @posValues ) && &TWiki::Store::topicExists( $webName, $name ) ) {
<             my( $meta, $text ) = &TWiki::Store::readTopic( $webName, $name );
>         if( ( ! @posValues ) && &TWiki::Store::topicExists( $webName, $title ) ) {
>             my( $meta, $text ) = &TWiki::Store::readTopic( $webName, $title );
> #SVEN - add processing of SEARCHES for Lists
>             $text =~ s/%SEARCH{(.*?)}%/&TWiki::handleSearchWeb($1)/geo;
Index: Search.pm
RCS file: /cvsroot/twiki/twiki/lib/TWiki/Search.pm,v
retrieving revision 1.47
diff -r1.47 Search.pm
<          @junk ) = @_;
>          $date, @junk ) = @_;

> #SVEN - this should be a call to &TWiki::Store::getWebList
<         $title = $field->{"title"};
>         $title = $field->{"name"};
> TWiki::writeDebug("getMetaFormField - $title , $name , $value ");
> TWiki::writeDebug("getMetaFormField - $title , $name , $value ");

-- SvenDowideit - 19 Mar 2003

I was trying to extend this to also allow the search to be used in the form itself, e.g., to have a formfield defined as follows

| Yet another | select | 1 | %SEARCH{"Iteration" noheader="on" scope="topic" nototal="on" nosummary="on" nosearch="on" format="$topic, "}% | |
with the idea being that the search would return a list of values that would be possible field values.

I added a call to web search similar to above:

        my @posValues = ();
        if( $posValuesS ) {
      $posValuesS =~ s/%SEARCH{(.*?)}%/&TWiki::handleSearchWeb($1)/geo;
     @posValues = split( /,\s*/, $posValuesS );
However, this does not work. Somehow, and here my limited Perl knowledge shows, the quotes disappear when this is passed into TWiki::handleSearchWeb, such that the search string ends up being the whole argument, rather than it being appropriately disected by TWiki::extractNameValuePair.

-- ThomasWeigert - 20 Apr 2003

One more question: In the patch to lib/TWiki/Form.pm the title and name fields are swapped. I don't quite see what good that does. It appears to me that this would break the retrieval of the definition topic. I did not swap these in my patched Form.pm and both changes, getting fields from a search ala SvenDowideit and using PeterKlausner's trick to retitle the topic still work.

-- ThomasWeigert - 20 Apr 2003

The nolinefeed parameter is a useful feature. I suggest to extend that by enhancing FormattedSearchWithSeparatorParameter.

-- PeterThoeny - 27 Sep 2003

The FormattedSearchWithSeparatorParameter and MultipleSearchesInSameTopic features are now implemented. I fixed above search example, the search in a TWiki table does work now with a separator=", " parameter.

-- PeterThoeny - 28 Sep 2003

Need field AssignedToCore filled in if this stays as FeatureToDo. It seems that left to do is:

  • Include processing of SEARCH tag
  • Consider other tags such as INCLUDE - extra linefeeds is an issue. This would be most useful where a separate topic is used to define possible values for field
  • Something like TWikiFormsDiffRendering

There is also a reference to HIDETEXTAREA, but this sounds like a different FeatureEnhancementRequest.

-- JohnTalintyre - 30 Sep 2003

Hello, I am a little lost. I have been looking for this feature, even though I am not sure I get the correct way to do it. I have a Form, this form uses a 'select' field (e.g. Users of my system). Now as this is a common field in several forms, I would like to make sure of a global definition which I can use in my form definition. Currently I am using the SEARCH functionality, even though every time I want to create a new form, instead of getting the combo control with the result of the query I get the combo control with the SEARCH*&^#... string. How can I make this?, how can I make my forms to dynamically update the possible fields? I tried the modification explained in the top of this page, even though it did not work... could you please help me in which changes I need to implement to get this working? thanks

-- GustavoAdolfoLopez - 30 May 2004

Marked as PatchProposal to expidite or cross-off.

-- MartinCleaver - 11 Sep 2004

The reason I want to do this is so I could dump a whole bunch of topics in with the form dictating the type and then use them as valid members of a population for a dropdown, i.e. to provide the detail fields of a TWikiForms? like TWikiForms#Defining_a_Form_with_Multiple_To

i.e. create topics as type "People" and then on another form say, select one person

-- MartinCleaver - 30 Sep 2004

It seems that this does not work in Cairo. Crawford suggested that it might be that the form doesn't get evaluated, and on inspection FormsDotPm , line 183 (TWiki20040901) does:

        my( $meta, $text ) = &TWiki::Store::readTopic( $webName, $form );
        @fieldDefs = getFormDefinition( $text );

I'd imagine that we'd have to get the page processed between those two lines.

Can anyone give me a reason why doing so would not be a good idea?

-- MartinCleaver - 30 Sep 2004

It wasn't quite there, (though the above patch might still be useful). It is here, line 202:

            my( $meta, $text ) = &TWiki::Store::readTopic( $webName, $name );
            @posValues = getPossibleFieldValues( $text );


         $text = TWiki::handleCommonTags( $text, $form, $webName );

and you can put a search in the population list to pull all topics of a certain type.

-- MartinCleaver - 30 Sep 2004

I'm trying to figure out what is the current status of this and related discussions (such as HandleCommonTagsInFormDef, TWikiFormsDontExpandVariables). Has a workable mechanism for dynamically defining form options using searches been implemented yet? Are we close? I've looked over these discussion but can't discern whether a solution has been found or not.

-- LynnwoodBrown - 14 Jan 2005

Is there any possible fix for allowing the query inside forms? Is there a chance that the latest version of Twiki contains this?, or is it being planned for a future one? Thanks!

-- GustavoAdolfoLopez - 10 Feb 2005

I have this now all working on Cairo. I will package all the various form enhancements up as an AddOnPackage shortly.

-- ThomasWeigert - 14 Feb 2005

As Thomas announced above, this feature is currently provided for Cairo with FormsAddOn, although apparently the compatibility of this add-on with upcoming DakarRelease is in question.

-- LynnwoodBrown - 07 Mar 2005

We are using this addon in our internal TWiki site, so I will be updating the addon to DakarRelease when it will be out... don't worry...

-- ThomasWeigert - 07 Mar 2005

I added in 4041 the following but left it inactive as I lost my testcase frown

Modified: twiki/branches/DEVELOP/lib/TWiki/Form.pm
--- twiki/branches/DEVELOP/lib/TWiki/Form.pm    2005-04-18 20:06:37 UTC (rev 4040)
+++ twiki/branches/DEVELOP/lib/TWiki/Form.pm    2005-04-19 01:31:31 UTC (rev 4041)
@@ -219,6 +219,9 @@
                  $store->readTopic( $this->{session}->{user}, $webName, $fieldDef->{name},
                                     undef );
                @posValues = getPossibleFieldValues( $text );
+# This probably implements http://twiki.org/cgi-bin/view/Codev/DynamicFormOptionDefinitions
+# But I accidently deleted my test case :(
+#              $text = $this->{session}->handleCommonTags( $text, $form, $webName );
                $fieldDef->{type} ||= 'select';  #FIXME keep?
            $fieldDef->{value} = \@posValues;

If anyone has time and a testcase, please uncomment the handleCommonTags and add the testcase to DevelopBranch.

-- MartinCleaver - 19 Apr 2005

What does this do? I am missing a clear description (for me) of this feature. Can someone create a problem/solution at the top of this topic, so that can be used for documentation (and my understanding)?

-- ArthurClemens - 19 Apr 2005

Ditto - and are you proposing this for Dakar? Because that is Dakar code, but this topic says it is Cairo only????

-- CrawfordCurrie - 19 Apr 2005

This is a feature I've been wanting for a couple of years, so I've taken a first stab of describing the feature as requested by Arthur. Of course, anyone should feel free to revise/refine this draft.

CDot - the reference to Cairo was in relation to the AddOn solution offered by Thomas and it probably not relevant to this discussion as a FeatureRequest in the core - which is where I believe it belongs.

-- LynnwoodBrown - 19 Apr 2005

In a spirit of experiment I fixed Martin's fix and checked it in. Would someone like to create a testcase, please? Use the ntwiki Sandbox web.

-- CrawfordCurrie - 19 Apr 2005

I think that if we make changes to the form, we should take the entire FormsAddOn into core, or at least, the key items. The code above is just a small snippet of the total problem.... If we are willing to consider adding some or all of the features of that addon into core, I am willing to port it to Dakar now, and do the doco, etc.

-- ThomasWeigert - 19 Apr 2005

I think Thomas' offer is excellent! Why recreate this wheel that already exist, particular which it comes complete with crome mags! smile Looking over the features provided by FormsAddOn, there are some features (such as designiating required fields) which seem like a logical extension of core TWikiForm features and the others (such as custom formatting) don't seem too extravagent to violate KISS. Thanks for the offer Thomas!

-- LynnwoodBrown - 19 Apr 2005

OK, I finished moving FormsAddOn over to Dakar. I would like to know which features would you like to see checked in:

  1. DynamicFormOptionDefinitions
  2. Mandatory fields
  3. Fixes to initialization via URL parameters
  4. Alternate rendering of form.

I'd like to keep at least the 1-3 together. 4 is independent of the others. I'd love to do the latter through a plugin, but the API is not sufficient (it be an easy change... we already allow to override the field rendering, why not the whole form rendering?) If there is support, I program the API also.

Please advise.

-- ThomasWeigert - 25 Apr 2005

Ok, great. How about check-in 1-3 now and do 4 as a separate API extension together with plugin? You surely know more about this than do any of us.

-- MartinCleaver - 26 Apr 2005


We are all of a sudden getting blank rows in http://develop.twiki.org/~develop/cgi-bin/edit/TWiki/TWikiPreferences....?

-- CrawfordCurrie - 28 Apr 2005

Not sure whether this is a bug, as it seems to be behavior per spec.

Here is the analysis of the problem: By spec the initialization of forms is as follows:

If a topic is created,

  • with a form only then
    • if there is text, do not initialize the form values
    • else take the initial values from form
  • with a template then
    • where the template has initial values, take from template
    • otherwise, use first rule.

This has the interesting consequence for labels, that these will never be set, unless they are being initialized without text, which probably was not the case when you created the TWikiPreferences. We could argue that the rule above should not count for labels, as they are intended to be used as labels, which should be there no matter what. But think about it this way... a label could also be used as a value that is changed not by a form, but by an application (e.g., I am using it often to keep track of things, such as the state of a topic). We would not want this to be taken from the form definition, if we happened to use an empty value.

Thus, I think the behavior is correct as it currently stands. Try this to see what I mean...

The second issue is that form fields without titles are not written out into the topic, and thus disappear upon save, even if created as above. So, as the untitled field is not stored in the form text, and as it is not initialized when the text is not empty, there will be an empty line displayed for each untitled field. Again, I think that is in spec, as by definition a form field must have a title and a type.

I could see that we change the spec to say that

  • the values for untitled fields are always taken from the form definition, as the user probably intended something with these fields, and certainly not an empty line.
We could, however, also say
  • that untitled fields are not allowed.

Please advise as to this spec change.

With respect to this particular feature, if you ask me, but that has already been discussed at another topic, this way of setting preferences half in the form and half in the text is a horrible practice. I am not fond of this at all...

By the way, TWikiPreferencesForm is missing a number of bars in many of the label columns.

-- ThomasWeigert - 28 Apr 2005

You reverted the behaviour to cairo behaviour; I had changed it to avoid untitled labels being dropped into topics. I thought it was a neat way to introduce labels into the form without cluttering up the topic with pointless label fields, This is a problem I have enountered many times before with forms, and not just when setting preferences. I think we should go with it (the changed spec, I mean).

I thought is was form fields without names rather than titles that didn't get written. We definitely do not want unnamed fields in the form data in a topic.

BTW did you see my mail and the SMELL I marked (expansion of SEARCH only)? I'm really uncomfortable about that.

-- CrawfordCurrie - 28 Apr 2005

Did not get your mail... please resend... I did notice the comment on SEARCH. Let me explain this... On DynamicFormOptionDefinitions we can use %SEARCH% to retrieve topics. So I guess you are concerned that there would be more variables in this search than just search itself (e.g., %WEB%). Could there be any other variables? I guess we could call handleCommonTags at the price of performance...

-- ThomasWeigert - 28 Apr 2005

On the forms...

  1. The name of the field is derived from the title (there is no way of creating the name itself). So not title, no name... unless we invent one...
  2. I definitely do not want to reinitialize fields that do have titles (and are stored in the topic) everytime we edit (as I need to use these fields for many purposes with meaningful content).
  3. I am ok with having untitled labels show up in the form as you had it planned. However, it would be best if those would be a spanned row in header style, rather than just a field without a title...

Please advise...

-- ThomasWeigert - 28 Apr 2005

The "price" is very small. Yes, there are other tags. For example, ACTIVATEDPLUGINS is an obvious one. METASEARCH is another.

This repeats something that MichaelDaum raised a while ago. There needs to be a generalisation of list handling. This is just another instance.

  1. No, let's not invent one
  2. Fair enough
  3. OK, sounds fine

-- CrawfordCurrie - 28 Apr 2005

On the handleCommonTags, experimenting with this I discovered that the key variables people would be using in the search are not handled by handleCommonTags, in particular %WEB%. I cannot see them using any of the variables that otherwise handleCommonTags is using in this search. I fixed the code now for dealing with %WEB%. I think there might be variables also for TWiki, and I guess I need to handle the attach webs also. Do you know off-hand whether there is a function that deals with substituting for all these?

-- ThomasWeigert - 28 Apr 2005

On your new spec for untitled labeled fields, please find this at SVN 4162. Please let me know whether this is what you had in mind...

-- ThomasWeigert - 28 Apr 2005

In particular, I am not sure about the font to use in those fields...

-- ThomasWeigert - 28 Apr 2005

Since there is no feedback, I assume the issue above has been resolved satisfactorily.

-- ThomasWeigert - 06 May 2005

Sorry Thomas, too many pans on the stove. Yes, that looks great!

-- CrawfordCurrie - 07 May 2005

There appears to be two new scripts in bin, settings and savesettings related to this. IMHO they are unneccesary - their function should be handled by action= params on edit and save respectively.

-- CrawfordCurrie - 21 Jun 2005

Done. 4470.

-- ThomasWeigert - 21 Jun 2005

Documentation checked into SVN 4556.

-- ThomasWeigert - 09 Jul 2005

Seems that not implemented is using INCLUDE to dynamically generate a form definition.

-- ArthurClemens - 11 Dec 2006

This functionality broke bunch of forms when we upgraded as we use variables to store the value displayed and selected. Previously the variable was also stored in the TWiki data, now it is resolved thus all our searches does not work anymore plus the managebility goes down considerably. It did actually help to wrap the option table (we use separate forms) in verbatim tags but of course it does not look very pretty. Some option on the form field definition is probably what we should have used here (resolve, do not resolve etc)?

-- OleCMeldahl - 14 May 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff TWikiForms.diff r1 manage 5.2 K 2005-07-09 - 17:31 ThomasWeigert Documentation
Edit | Attach | Watch | Print version | History: r59 < r58 < r57 < r56 < r55 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r59 - 2007-05-14 - OleCMeldahl
  • 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.