In theory we can have some JS script that can be usable in client AND server sides. If these scripts contains no dependencies with flowscript objects (cocoon, etc) and Java code we can deploy to both sides!
However what I'd like to see is to reuse the validation rules in the form-definition. Implementing "assert" is much more difficult. As Sylvain wrote, should be quite simple to implement three kinds of validations: check on field presence, basic format checks and a custom function. This should cover the 90% of user requirements. We need this feature soon, so I've thinked to write a transformer that enrich the form instance with javascript functions (Decorator Pattern) and can be placed in the pipeline just before the final XSL. The generation should write one check-function per widget since the control may occurs on focus change (onBlur) or on submit. If the transformer works fine some committer may decide to englobe it in the CForm lib. Bye, Luca Garulli www.Pro-Netics.com (member of Orixo.com - The XML business alliance) OrienTechnologies.com - Light ODBMS, All in one JDO solution On Mon, 22 Nov 2004 20:05:58 +0100, oceatoon <[EMAIL PROTECTED]> 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. > > Regards > Tibor
