Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>>
>> 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:
Should work either. Maybe the guys with the usecases can tell us more and then
we talk about the abstraction level.
--
Reinhard
|