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.

Operation:

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.

                blob 
                boolean
                ccexp
                ccnum
                cctype
                counter
                country
                dateYMD     # YYYY-MM-DD
                dateYMDHMS  # YYYY-MM-DD HH:MM:SS
                dirname
                domainname
                email
                enum
                enumtext    # must have list val1,val2,... following.
                int8
                int16
                int24
                int32
                int64
                ipaddr
                money
                numeric
                password
                pathname
                percent
                intdegrees
                degrees
                phonenum
                spercent
                state
                status
                taxid
                text
                timestamp
                URL
                vartext
                zip
                weight

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