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
