cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <esa...@canuck.com>
Subject Re: using Schemas for Form validation
Date Sun, 25 Jun 2000 15:51:38 GMT
on 25/6/00 4:40 pm, Giacomo Pati at Giacomo.Pati@pwr.ch wrote:

> Mark Washeim wrote:
>> 
>> on 25/6/00 4:01 pm, Jeremy Quinn at jermq@media.demon.co.uk wrote:
>> 
>>> Hi,
>>> 
>>> I am (still) planning a TagLib to handle the interaction between html forms
>>> and XML files on disk. Hopefully a TagLib version of Donald's XMLForm.
>>> 
>>> I was planning a "constraint" mechanism to allow the author to set up tests
>>> on the input that have to be passed before data is written.
>>> 
>>> It was set up in such a way that a set of parameters defining a contraint
>>> are passed both to the constraint engine and output to the XSL so that a
>>> client-side JavaScript can be assembled.
>>> 
>>> I just started looking at the possibility of using Schemas instead.
>>> It would save me a lot of work and be more standards compliant.
>>> 
>> <SNIP>
>> 
>> Just a suggestion based on recently implementing 'self-validating' forms.
>> Though, I'm actually partial to schema, for the sake of simplifying
>> maintenance, I recently build the following:
>> 1. validation beans which match constraints specified in
>> 2. the form xml itself
>> 
>> The xml looks like:
>> 
>> <MEMBERFORM type="page">
>> <FORM method="post">
>> <ACTION>member.xml</ACTION>
>> <HIDDEN name="action" value="checkForm"/>
>> <HIDDEN name="target" value="thanks.xml"/>
>> <HIDDEN name="page" value="Membership"/>
>> <TEXTINPUT
>> name="USERNAME"
>> value=""
>> title="*Username"
>> type="text"
>> size="16"
>> maxlength="64"
>> required="TRUE"
>> /><TEXTINPUT
>> name = "PASSWORD"
>> value=""
>> title = "*Password"
>> type="password"
>> size = "16"
>> maxlength = "8"
>> required="TRUE"
>> /><TEXTINPUT
>> name = "PASSWORD2"
>> title = "*Confirm"
>> value=""
>> type="password"
>> size = "16"
>> maxlength = "8"
>> required="TRUE"
>> compare_field="PASSWORD"
>> /> <TEXTINPUT
>> name = "EMAILADDRESS"
>> title = "*Email address"
>> value=""
>> type="text"
>> size = "16"
>> maxlength = "128"
>> required="TRUE"
>> contains="@"
>> />
>> ....
>> 
>> The constraints are arbitrary fields (compare_field, contains).
>> 
>> These forms are in-lined into a node (cloned-in), first being passed to a
>> class level method which,
>> 1. checks the request for the action
>> 2. if it's not yet been posted, just pass through to the node
>> 3. if the request contains the action, checkForm, for instance,
>> a) for each type of input, instantiate a checker bean,
>> b) pass each value set to the bean (bean returns condition string ('Did not
>> match', 'Did not contain:', etc)
>> c) member method checkForm uses util methods to re-populate the FORM DOM
>> with results, or the request values, depending on conditions...
>> 
>> The long and the short of it is, that this permits one document to behave as
>> data model ...
>> 
>> I realize that this is a little bit 'overloaded', however, if you maintain
>> multiple language versions (I have six languages), it's quite convenient . .
>> . often, the same form is used through multiple passes ( populateFromXML
>> (including sql), checkForm(request) . . .)
>> 
>> If anyone's interested, I'll post complete examples . . .
> 
> Yes, I'm interested. Please post it (even privately).
> 
> Giacomo

Ok, this is a hack version, attached as a zip. It does NOT contain the
checker beans and is basically the prototype. Please, don't bother to point
out how SUCK the code is :)

What you get:
member.xml
update_member.xml

two xsp pages which both import the same logic (using the parser) . . .

The class level methods permit:
a)importing the form xml (or any other xml)
b) populating a form from another XML file (note:requires parity between the
element names of the xml used to populate the form and the field names of
the form itself. we use column names from SQL strictly in the forms to
permit ease of maintenance, though it DOES expose you, we md5 hash
everything in production)
c) checking the values on the request against the rules in the xml form. in
this version, the conditions are just subbed into the field value. not
effective, as you'll see for the password field. .  .)


the form specifies it's own accounting, so to speak:

<ACTION>member.xml</ACTION>
<HIDDEN name="action" value="checkForm"/>
<HIDDEN name="target" value="thanks.xml"/>
<HIDDEN name="page" value="Membership"/>

the checkForm method checks whether to pass the form back out, or scrutinize
input on the basis of whether or not 'action' is in the request (happens on
form submit). if action is checkForm, checkForm uses checkFormFull to
compare the request name/value pairs against the form xml (this is a crude
example, keep in mind) . . .

If the check's fail, the form dom is repopulated (the attribute values set)
in accord with the condition....

I haven't supplied any, but target specifies the page that will handle the
validated input. In production, this is usually an xsp page which handles
the submit via the sql: taglib . . . NOTE if you wish to use this approach,
make sure that your field validation (which is cursory in this example) is
thorough. Otherwise, you may have someone writing spurious data ...


When I have some time, I'll post a proper version. But, if your inclined,
have fun . . .



-- 
Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell

 



Mime
View raw message