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 14:22:54 GMT
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 . . .


-- 
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