Tags:
create new tag
, view all tags

Form Input Validation

Yesterday (19 Feb 2007 ) I had lengthy discussion with CDOT on IRC about form input validation. Have no idea who that is, but seemed very knowledgeable in TWiki.

We came to the conclusion that there are two types of validation for form data, trivial and non-trivial. Trivial validation is basically matching against some pattern mask to make sure that input in a valid format. Non-trivial, is validating data input against some data source. Other topics, databases, etc...

Cdot also recommended that trivial validation could be done in a JS script on the client side. I do agree with that, but I think it should also be done on the server side, just like mandatory field check is being done. Another point of the discussion was to implement it entirely as plugin using beforeSaveHandler.

So this brain storming is at the moment is centered around trivial input validation on the server side. Once the logic for server side is in place the JavaScript part is simple to do using beforeEditHandler.

I did some research today to figure out what it would take to implement the beforeSaveHandler. To me (at least) it seems that I have to run through the same gambit of of code as is done by buildNewTopic() in TWiki::UI::Save to figure out which (if any) form that I'm dealing with. Basically the code in buildNewTopic() does this to find the Topic's form (along with many other stuff):

  1. Check to see if formtamplate CGI parameter is present use that as the formname; else
  2. Check to see if there is a tempaltetopic CGI parameter, if it is there get the template's META:FORM and use that; else
  3. Check to see if the topic's META:FORM is set, use it; else
  4. No processing on form to be done (basically no form is associated with the topic)

Basically this flow implies that if 1. is true, then it is a new topic with a form template. If 2 is true then it is a new topic with a topic template that has a form. If 3 is true then it is an already existing topic.

So, to implement it in a Plugin this code would have to be duplicated or it needs to go into a function accessible by Plugins.

But to me it seems that it would make more sense to add some code in buildNewTopic() to do the form validation in the if ($formDef ) block around line 216 in UI::Save.pm and add a sub to the TWiki::Form class similar to the getFieldValuesFromQuery() sub.

Specifying the input mask

Use input mask ie, ###-###-#### or use regex or both. I personally like regex, maybe have some predefined rules.

This could be specified in new column in a form's table:

| *Name* | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* | *Validation* |
| TopicClassification | select | 1 | NoDisclosure, PublicSupported, PublicFAQ | blah blah... |   |
| OperatingSystem | checkbox | 3 | OsHPUX, OsLinux, OsSolaris, OsWin | blah blah... |   |
| OsVersion | text | 16 | | blah blah... |   | "^\d{3}.\d{3}.\d{3} " |

Or, since Attributes is parsed using TWiki::Attrs class, can just add an attribute to the list:

| *Name* | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* | *Validation* |
| TopicClassification | select | 1 | NoDisclosure, PublicSupported, PublicFAQ | blah blah... |   |
| OperatingSystem | checkbox | 3 | OsHPUX, OsLinux, OsSolaris, OsWin | blah blah... |   |
| OsVersion | text | 16 | | blah blah... | M validation="^\d{3}.\d{3}.\d{3} " validation_help="Version should be numbered ###.###.###" |

#2 means no change in the parsing code. -- Contributors: DimkaShwabra - 20 Feb 2007

Basic flow

I'll outline both the Plugin method and core method

Plugin

  1. in beforeSaveHandler do all of the stuff to figure what form belong to a topic
  2. load the table and get the mask from the new column/attributes for fields
  3. Check the cgi parameters from form input against proper mask
  4. On failure through an Ooops.

The BAD thing: Have to parse the form table twice, once in the core once in the module, Unless $formDef can be showed away into the session object, this still requires modification to the core.

The good thing: Would not require core to be modified.

Core

  1. Add validateFormInput (or something) to TWiki::Form, this routine would return two array, fields that passed the test and fields that failed the test
  2. In UI::Save.pm in buildNewTopic() put code into the if ($formDef) block to cal the validateFormInput
  3. If anything is in the failed fields array, throw an Ooops

The good thing: the parsing of the form table has to be done only once

The bad thing: Have to modify the core, but I think this functionality belong there any way.

Core + Plugin

Modify core to store away the formDef into session, then implement the plugin this eliminates the need to do step #1.

I like this the most, now that I think about it.

Discussion

CDot is CrawfordCurrie.

-- LynnwoodBrown - 21 Feb 2007

There is a plugin handler (renderFormFieldForEditHandler) that could be used to emmit the proper javascript for validation, when you get to that.

-- RafaelAlvarez - 21 Feb 2007

All of that is irrelevant it appears, since all of the form stuff if available in the META object that is passed to beforeSsaveHandler.

-- DimkaShwabra - 21 Feb 2007

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2007-02-21 - DimkaShwabra
 
  • 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-2016 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.