cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Client side validation
Date Mon, 22 Nov 2004 22:44:33 GMT
oceatoon wrote:

>Sylvain Wallez wrote:
>
>  
>
>>[Moving a private email to dev@ as it's really where it should be
>>[discussed]
>>
>>Luca Garulli wrote:
>>
>>    
>>
>>>Hi,
>>>my customer want a minimal client-side validation for same fields. We
>>>are using CForms and seems to be lack of this feature.
>>>
>>>I'd like to have a single place where to describe validation rules:
>>>the form definition. Anyone has implemented something like a
>>>client-side validation that use the form-definition rules?
>>>
>>>If not I can start to write it. I think that it's a common use case.
>>> 
>>>
>>>      
>>>
>>Yes, that's a common use case and we already talked about it but never
>>got the time to implement it.
>>
>>There are different kinds of client-side validation
>>- field presence for required fields
>>- datatype syntax : integer, date, taking the locale-dependent format
>>into account
>>- additional validations.
>>
>>The first item should be easy, and the second one can leverage the
>>datatype information that is already present in a field's XML output
>>(used e.g. to trigger the use of the calendar widget)
>>
>>The third one is trickier, as some validation rules can be controlled on
>>the client (e.g. range, regexp) whereas others can't. What we can do
>>here is adding a generateSAXFragment to validation rules also, so that
>>those rule that can be implemented on the client can produce an XML
>>description that will be translated to JavaScript by the presentation
>>stylesheets.
>>
>>WDYT?
>>    
>>
>
>Sorry to walk into post but this mailing list is amasing, answers come up
>simultaneously to my personnal questions, thx for reading my mind ;) I am
>exactly on this problem coz formy case Server side validations is a bit too
>heavy. I'd be glad to help if needed since our project will need it too
>
>Would this mean, Client side JS would be written in the models validation
>tags, and the form generator would return something like this:
><fi:CJS>
>        JScode or call2function.....
></fi:CJS>
>where JScode would be directly connected to the input @onchange for
>example : <intput type="text" onchange="JScode"/>
>
>and 
>
>call2function would call a function that is either written in the model and
>iserted, either written or included directly in the page containing the
>ft:form-template and the concirned widget . 
>
>unfortunetly I'm more of a user and I can deal with the stylesheet or JS
>development if the SaxFragment sends the fi:CJS, but I'm not familiar with
>insides of CForms.
>  
>

I once proposed that validators could produce a small snippet of JS that 
would be included in the produced page. However, this somehow mixes some 
client-side technology in the validators which isn't a good thing.

So the idea now is that a validator produces an XML representation of 
itself, which could be a simple as it's definition translated to the 
"fi:" namespace.

E.g.

<fd:field id="foo" required="true">
  <fd:datatype base="integer"/>
  <fd:validation>
    <fd:range min="1" max="10"/>
  </fd:validation>
</fd:field>

would produce
<fi:field id="foo">
  <fi:datatype type="integer"/>
  <fi:validation>
    <fi:required>
    <fi:range min="1" max="10"/>
  </fi:validation>
</fi:field>

It's then the job of the presentation XSLs to transform <fi:range> into 
something useful.

Only those validators where a client-side implementation is possible 
would produce an XML fragment in the <fi:validation> element.

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message