Tags:
create new tag
, view all tags
A few ideas for what the FormTemplateSystem could be used for in the future.

Workflow

Some small change could enable a simple workflow system e.g.

  • Triggers on field changes - could go via new Plugin calls
  • Switching between form templates e.g. to constrain field values - mostly implemented
  • Change fields to readonly

For security settings

Allow setting of read/change security settings. If you want a form for this and something else one could:

  • Put fields together on one form
  • Allow inheratance of fields between forms
  • Allow multiple forms

At present the full topic must be read, before you know if user has view/change permissions, could enforce as META data at the top of the file, so that reads can be faster for initial security check.

For general settings

TWikiPreferences and WebPreferences could hold their data in forms. Would need:

  • Something for multivalue entries
  • Selectors for people ...
  • Decide if Set to be kept as well e.g. for adding variables without defining them for form.

New widgets

For those happy to use DHTML, lots of new widgets (on top of text, radio etc) are possible e.g. date control with validation and GUI for picking date. I think best way of doing this would be via new Plugins functions.

-- JohnTalintyre - 26 Jun 2001

Put main textarea into form

From RichardDonkin

The TEXTAREA widget is just a special type. It would be useful to be able to include that in the form template. That way you have control where the TEXTAREA is in regards to other form fields, i.e. you could set the form fields above the free form TEXTAREA, or you could get rid of the TEXTAREA all together to get a true form. Note: Probably best to postpone that until after the release.

-- JohnTalintyre - 16 Aug 2001

Default Values and Required Fields

Some other things that are needed with forms that I haven't yet seen mentioned:

  • Mechanism for setting default value(s) for any form element in the form definition. It should allow the use of %VARIABLE% expansion when the form is instantiated into a topic.

  • Mechanism for making a field required, for some definition of required.

As JohnTalintyre mentioned above, putting in the ability to perform actions on the form data could handle the required mechanism by entering a table like:

Name Type Size Values Tooltip Message Preaction Postaction
ProductRevision select 10 -- select --, 4.0.3, 4.0.4, 4.0.5, OTHER Must select product version required required
email_address text 40   Your email address get_email{"% WIKIUSERNAME%"}, required required,email_valid('X.400_check')

The Preaction (if any) would be called and its result would be used to set the default values of the field. The first returned variable will be some html that is used as a prefix to the field name (e.g. ** to show field is required). The second value will specify the default value for the field as though it was retrieved from the META:FIELD value=... key. It would be called as:

  • ($formatting, $metaValueString) = preaction("$META:FORM{'name'}.$META:FIELD{'name'}", @preactionargs)
an example would be:
  • ($form, $val) = get_email_preaction("TwikiForm.email_address", "% WIKIUSERNAME%") )

In this case, the returned values are: $form is empty, and $value is rouilj@ieeePLEASENOSPAM.org. Another example is:

  • ($form, $val) = required_preaction("TwikiForm.email_address")

would set $form to be "**" (appropriately encoded), and leave $val empty which would mean to leave the value, obtained from previous preaction or other source, alone.

The Postaction could follow along similar lines, except that any return value except "" is an error message to be presented to the user. So:

  • $errormessage= required_postaction("TwikiForm.email_address")

could return "Field email_address is required. Must not be empty\n". While

  • $errormessage= email_valid_postaction("TwikiForm.email_address", 'X.400_check')

could check to see if the email address is "valid" either a local username in the passwd file or a user@host where the host name lookup works. Since it has the 'X.400_check' it will also return ok for a valid X.400 email address. Any form of validation could be done this way.

One problem is that it may result in multiple correct/preview or correct/save cycles since I have no mechanism for running multiple preactions and gathering all the info from them. Since some of the preactions may cause side effects (e.g send mail) the data validation actions would have to be applied and passed before any other preactions are executed.

The action functions may need some more functions in func.pm (I think that's the plugin library right??). E.G.

  • @values = getvalues($_[0]) - gets the values from form template.
  • $type = gettype($_[0])
  • $curval = getcurrent_value($_[0]) - gets values from metadata.

to generate an appropriate return value. Also should the pre/post function names be twiki words to go along with the other plugins?

Quips, comments, evasions, questions and answers always welcome.

-- JohnRouillard - 23 Nov 2001

UsingFormsForSettings has come up in a few places - I'm thinking of moving it forward.

-- JohnTalintyre - 23 Jan 2002

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2002-05-05 - MikeMannix
 
  • 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-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.