cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Client side validation
Date Tue, 23 Nov 2004 08:14:05 GMT
Sylvain Wallez wrote:
> 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.

yep, that's the way to go! If widgets produced Javascript themselves, we would 
mix concerns because not all clients support Javascript or you need different 
Javascript "dialects" for different clients. Following Sylvain's proposal it's 
the stylesheet's job to create working valdiation programms.

We should also think of a way how and where we can add custom client-side 
validators. If we add this to the form defintion we would need some kind of 
abstract language, or at least Javascript with an abstract object model:

   if($widgetXY.value$ <= $widgetZZ.value$ {
	return "i18:value-to-high";
   return true;

This could be transformed into something valid for the client by replacing the 
$...$-tokens through valid pointers to the client's object model.


View raw message