cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Client side validation
Date Tue, 23 Nov 2004 09:12:52 GMT
Reinhard Poetz wrote:

> Sylvain Wallez wrote:

>> 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?
> 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:
> <ft:client-side-validation>
>   if($widgetXY.value$ <= $widgetZZ.value$ {
>     return "i18:value-to-high";
>   }
>   return true;
> </ft:client-side-validation>
> This could be transformed into something valid for the client by 
> replacing the $...$-tokens through valid pointers to the client's 
> object model.

Or simply an abstract getWidgetValue(name) function that would have 
different implementations server-side and client-side? That way, we 
don't need macro expansion and we can use a single JS snippet for both 
client and server-side validation.

Of course, not every JS validator can run client-side, and that needs to 
be distinguished with a particular attribute:


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message