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?
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.
-- Reinhard
