create new tag
, view all tags
In dialog engines I have been involved with in the past, there was a need for a number of datatypes that could be checked for validity when submitting a form. Currently, TWiki has a limited number of datatypes which really are not used for checked the validity of the entry, but simply for determining the form of display.

Here is my recommended list of datatypes and what they are (We have had need for these before):

  • zip - US zip code
  • taxid - US Federal taxid number
  • state - US and CA two-digit state code.
  • email
  • email_list
  • phonenum
  • password
  • password_new
  • password_confirm
  • dateYMD - standard YYYY-MM-DD format, MM and DD may be omitted.
  • country - two character country code
  • ccnum - valid format credit card number (just checksum check)
  • percent - decimal value between 0 and 100 inclusive
  • spercent - signed percent.
  • intdegrees - integer degrees (0-360 inclusive)
  • degrees - decimal value 0-360 inclusive
  • numeric - some decimal number
  • money - leading $, +/-, embedded commas OK.
    • Should be configerable for different currency symbols. -- SamHasler - 19 Nov 2003
  • plusmoney - no '-' allowed, otherwise money
  • URL - full possibility.
  • domainname - just the root name and tld.
  • dirname - dirname must be plain word with no spaces and no extension, underscore OK.
  • dirpath - dirpath must exist on the system as a directory.
  • filename - can't start with '.'

Twiki Specific

  • twiki_user - Existing User, fully qualified.
  • twiki_group - Existing Group
  • twiki_topic - Existing Topic ...etc.


When page is submitted with such a form, submission would fail with explanation unless proper datatype is entered.

-- RaymondLutz - 19 Nov 2003

Much can be done through the plugin API. See examples in FormFieldsPlugin Note that this would allow client side JavaScript controls, but we would need an extra plugin hook to do server side validation.

My prefered route would be:

  • Add server side validation plugin hook
  • Distribute something like FormFieldsPlugin with implementation of some of the above (IMO some of the above are questionable e.g. dirpath as described above)

Then people can use if they want to and most importantly can change their local version.

-- JohnTalintyre - 19 Nov 2003

Generally, I like your idea for implementation.

FYI, the dirpath type is useful for installation scripts although indeed it would probably be worthless for the simple forms available for TWiki now, i.e. data is simply included in META fields.

-- RaymondLutz - 19 Nov 2003

Forgive me if I've misunderstood, but how do installation scripts tie in to a TWiki Form? dirpath is described above as "dirpath must exist on the system as a directory"; for most TWiki installations you wouldn't expect users of TWiki to have knowledge of or need to interact with, the path on the system. Did you have in mind some special situation where there was a more explicit link to the file system on the TWiki host machine?

-- JohnTalintyre - 20 Nov 2003

I listed the datatypes we used for a fairly large imaging-oriented application (http://www.imagingweb.com). Therefore, the need for degrees of rotation, etc. In that case, we needed to supply administrator-oriented dialogs to manage the system, including where the high-resolution images would be found, etc. In TWiki, there is a shortage of such administrator-oriented control panels, and currently the install requires a lot of fiddling with directories, etc. "It would be nice" if this stuff was more automated. But this is really off the point. If you don't ever want to use the datatype, just don't use it. There are probably more that others would want to use.

I forgot one important detail: required vs. optional. You need to be able to state whether the form field is required, i.e. filled in and proper form before the form is accepted.

Now, in a different dimension, if TWiki is ever to interface nicely with database engines, you also would like to know something about the perceived storage requirements. I have this list with regard to interfacing with many database engines, including MySQL. The datatypes I show here are NOT the terms actually used by a specific database, but they map into a specific data implementation.

                dateYMD     # YYYY-MM-DD
                dateYMDHMS  # YYYY-MM-DD HH:MM:SS
                enumtext    # must have list val1,val2,... following.

Therefore, there are three components

  1. The format of the data that is acceptable when the user enters it.
  2. Whether the field is required or optional.
  3. The storage requirements. Many datatypes, like "state" have a fixed and known database implementation. Others, like text or numeric need some more definition to allow the database to be as concise as is practical.

-- RaymondLutz - 20 Nov 2003

As I understand it dirpath would validated to check it is a valid path on the server. For security reasons this should perhaps not be turned on in a default installation.

-- SamHasler - 21 Nov 2003

I looked back at the times when we used that and it related to supplying a file for operation by a server-based agent. Given the architecture of TWiki, I don't think we will need that one, so consider it omitted for now.

-- RaymondLutz - 21 Nov 2003

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2003-11-21 - RaymondLutz
  • 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.