How do you pass values to form fields in the newly created topic? Is this broken or not implemented yet?

• I did not think of a way to implement this yet -- SD
• in the same way I have not hought of a way to implememnt using this to modify a topic (not just append) -- SD

-- ArthurClemens - 06 May 2004

To make this consistent, the save script should understand the same URL parameters like the EditCgiScript. A quick scan on edit shows this:

The direct save feature can be dangerous. To reduce the risk I propose to add one required parameter with these values:

Any combination is possible as well, e.g. saveaction=create+update, but at least one of the defined values must be present (or an error of incorrect use is returned)

The existing preview should issue the saveaction parameter for the SaveCgiScript. HTML forms that create a topic on the fly must specify a hidden saveaction input field.

One additional issue: Form fields of an existing form should be preserved on a direct save unless overridden. Currently all fields are removed because of the TWiki::Form::fieldVars2Meta( $webName, $query, $meta ) call.

Update spec above when finalized.

-- PeterThoeny - 07 May 2004

Attaching a preliminary version of NoEditAddOn add-on for those who want to try out. It is not based on specs/discussion here, but performs similar tasks. It allows document to be uploaded to topic. This can be a good starting point. (Undocumented: %PUTATTACHMENTHERE% is replaced with the link to attachment, as per the standard "add link" approach. This hack will be removed in favour of FILELIST approach that was requested in FormattedVarForAttachmentList.)

• NoEditAddOn-0.2.tar.gz: NoEditAddOn - Allows topic creations without going via edit.

-- VinodKulkarni - 29 Jul 2004

Virtual Topics: One neat idea is that the script newtopic can create a concept of virtual topic. Virtual topic (like aliases) is dynamically created from a template, and some data looked up from database or elsewhere. For example, UserXyzAbc will be first treated as non-existent topic and will be invoked with newtopic script. This script will lookup for matching virtual topic template (based on the pattern of this new topic). If found, it will pass the matched $1, $2 to the template. The template will use appropriate macros (interface with ldap, database) to render the content.

Automatic topic linking to shift to view time: Rather than letting wiki-word patterns to autolink at render time, send them to newtopic script. This will look for appropriate topic at run time and render the topic. (So we have three alternatives now: Autolink, NOAUTOLINK, and POSSIBLY_A_LINK.)

-- VinodKulkarni - 30 Jul 2004

I've been doing some testing to figure out status of this feature, specifically in regards to inserting values into forms. Here is what I've found so far (using develop branch build 4365):

• Using SaveContentWithoutEdit to create a new topic, url parameters do not get passed to form fields. I've tried both referencing a template topic (that includes a form) and a form template (although I'm not sure about syntax for later).
• Using SaveContentWithoutEdit to change a form value in an existing topic will insert the form value but will delete all other form values as well as the topic text.
• All my attempts at specifying a form template results in a topic that has the name of a form, but no form (and, of course, no values in the form).

CrawfordCurrie asked me what I expected to happen and my answer is that I would expect, as PeterThoeny suggested above, "the save script should understand the same URL parameters like the EditCgiScript." More specifically, I think SaveContentWithoutEdit should follow the same specifications for order and priorities of form field intialization proposed by ThomasWeigert in AllowFormTemplateWithTemplateTopic:

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.

In addition, I would draw attention again to PeterThoeny's recommendations above regarding a saveaction parameter.

-- LynnwoodBrown - 10 Jun 2005

Reverse engineering save, here's the current situation.

If templatetopic is not specified, and a form is attached to the topic (either because there was one there already, or because a form was specified using formtemplate), then form field values will be pulled from the query. If templatetopic is specified, values will be taken from the template topic and the values in the query will be discarded.

Further, if the topic name contains a sequence of at least ten X's, (XXXXXXXXXX) all the sequential X's will be replaced with a number which is auto-incremented until the topic name does not conflict with any existing topic.

-- CrawfordCurrie - 14 Jun 2005

Very helpful! Thanks Crawford!

I would add the additional observed behavior:

One minor question (for you or anyone): what value does one use for formtemplate ? The form definition topic? When I tried this (i.e. creating a new topic and providing only a value for formtemplate ), I got a topic with the form name displayed where the form should be but no form.

The next, bigger question is how much work will it take to be consistent with Thomas' outline above for order and priorities of form field intialization? In particular, I am interested whether we can get it to accept a templatetopic and form field values (as it does when going to edit). It seems to me that this would be the most common "use case" for this feature.

-- LynnwoodBrown - 14 Jun 2005

I already covered handling of form field data in the text.

formtemplate needs to be the name of the form i.e. the form definition topic. It has to be in the same web (SMELL).

It seems perfectly reasonable to me that form field values in the query should override those in the template topic; I can't really understand why it was implemented the way it was. The in-code documentation gives no clues. I guess from Peter's comment above it was not for any particular reason.

Is anyone going to start a riot if we change the behaviour so that form field values in the query override values coming from the template topic?

Specific proposals:

1. Change the behaviour of save so that:
   1. If a templatetopic is specified, values for the fields are taken from (in order):
      1. The query,
      2. the previous version of the topic,
      3. the form attached to the templatetopic,
      4. if a formtemplate is specified, the formtemplate definition.
   2. If no templatetopic is defined, values for the fields are taken from
      1. the query,
      2. the previous version of the topic,
      3. if a formtemplate is defined, the formtemplate definition.
2. Refactor the documentation in this topic into the documentation set.
3. Support the use of forms in other webs with formtemplate

Lynnwood, any chance you could document a testcase for this, that covers all cases? Ta.

-- CrawfordCurrie - 15 Jun 2005

Glad too! I'll send you link for draft test case for you to modify as needed and check in to svn.

-- LynnwoodBrown - 15 Jun 2005

Well, here's my first SVN checkin! The test case is in SVN 4408, 4409, and 4410.

-- LynnwoodBrown - 22 Jun 2005

OK, thanks Lynnwood. There's not much point in attacking the errors until Thomas has finished incoporating the savesettings script. So we are now waiting for Thomas (DynamicFormOptionDefinitions).

-- CrawfordCurrie - 22 Jun 2005

Sorry for the delay. The required updates to DynamicFormOptionDefinitions are done... I did integrate the settings/savesettings scripts into the manage script, as it calls functions from ManageDotPm....

-- ThomasWeigert - 30 Jun 2005

The change in SVN 4421 has broken SupportTopicSpecificTemplates by not preserving meta data. Fixed in SVN 4567.

-- ThomasWeigert - 10 Jul 2005

Are we all done here? Can we close this topic?

-- CrawfordCurrie - 11 Jul 2005

Where can I find the documentation?

-- ArthurClemens - 11 Jul 2005

TWikiScripts

-- CrawfordCurrie - 11 Jul 2005

There were some comments on attacking errors as a response to Lynwood. Not sure where that stands. From my end everything is done.

-- ThomasWeigert - 11 Jul 2005

Any further issues should be reported as bugs to the Bugs web. Thanks.

-- CrawfordCurrie - 12 Jul 2005