Hi William, Maybe this is overkill for your application but I wrote a TCF a while back that both presents and checks forms in two different methods. To create a form I simply call the tcf with the name of a text file that has all the form setup information. Columns in that text file are something like...
Verbose name Database name Required field (y/n) Field type (Text/Number/select/radio/money/date etc) Field size Options (name of array with options, for choicelists) Values (name of array with values, for choicelists) Previous value (name of variable with previous value) Etc... So a few lines of a sample Form Definition text file might be First Name,fname,y,text,25,,,MyValues[1,fname] Last Name,lname,y,text,25,,,MyValues[1,lname] Birth Date,dob,y,date,10,,,MyValues[1,dob] It took a while to write and debug but now I reuse it for many clients, and new forms are a snap. Plus I can do some special checks on custom types like "money" and "date". Hope this is helpful! Quinn McLaughlin > -----Original Message----- > From: William M Conlon [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 21, 2005 12:37 PM > To: Witango-Talk > Subject: Witango-Talk: Form validation -- Request for Comments > > I've been meaning to build a general purpose form validator, > and have run into an immediate need, so I think I'll work on > it. Here's my > thinking: > > 1. Form fields would be named in some maintainable manner: > either reflect the table and column, the form and field. For example, > > <input type="text" name="users.email" value="<@COLUMN > "users.email"> size="30" maxlength="255" /> > > or > > <form name="update_user" action="... > <input type="text" name="update_user.email" value="<@COLUMN > "users.email"> size="30" maxlength="255" /> > > 2. I would keep a table of all the form input fields: > > table > column > required > validator > format > > This would get queried and cached in an app or domain scope array: > > form_input_name, for example users.email (concatenated from > table and column length (from DESCRIBE TABLE) type (ditto), > but this might not be needed required (yes/no) validator (a > metatag or method that processes the data) format (a FORMAT > attribute to be applied to the variable in the SQL statement. > This is why I need this -- I need to make sure that some > inputs are converted to mySQL date format). > > This approach would be if I thought that I could apply the > same validation a column, no matter what form was submitted. > > On the other hand, it might be better to use the form.field > approach, because I could then verify that the form was > allowed to be submitted by the user > > 3. On form submittal, run a method: > a) Save all validly named POSTARGs into witango variables, > eg., @@user $users.email > b) check that all required fields are present > c) trim all saved variables to length > d) apply the validation function. > > Now here is the queston: how do I implement the validator? > One approach would be to store witango code in the validator > column and execute that upon the data. Can this even be > done? Run-time generation of witango code? > > Or store a validator index in the table and then call a > validator method with the index and the input variable as parameters: > > Case 1: > <@ISDATE @@method$parameter> > Case 2: > <@ISNUM @@method$parameter> > Case 3: > <@CALLMETHOD OBJECT=... > Case n: > > Anyone have any other thoughts, suggestions? > > Thx. > > Bill > > William M. Conlon, P.E., Ph.D. > To the Point > 345 California Avenue Suite 2 > Palo Alto, CA 94306 > vox: 650.327.2175 (direct) > fax: 650.329.8335 > mobile: 650.906.9929 > e-mail: mailto:[EMAIL PROTECTED] > web: http://www.tothept.com > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
