cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal Bhatt <>
Subject Re: Client-side validation in CForms
Date Thu, 10 Jul 2008 23:51:05 GMT
Jeremy Quinn wrote:
> Dear Kamal
> Many thanks for your response.
> On 9 Jul 2008, at 23:18, Kamal Bhatt wrote:
>> Jeremy Quinn wrote:
>>> Hi All
>>> As you may know, I am working heavily on the revamp of Dojo on the 
>>> client-side of CForms.
>>> In Dojo it is possible to perform quite a lot of validation on form 
>>> fields. There is a partial match between the validation capabilities 
>>> of CForms and those of Dojo. Several people have thought in the past 
>>> that it would be good to have the same validation occur on both the 
>>> server and the client.
>>> OTTOMH, the kind of validators we could probably make work in both 
>>> places would be :
>>>    email, length, mod10, range and regexp (plus maybe javascript, if 
>>> we can sort out any context differences)
> On re-examination, the list of validators that could have an 
> equivalent client-side validator auto-generated is probably shorter 
> ..... as I am not sure ATM how to implement the expressions possible 
> in some of them ..... eg. assert, length, range etc.
>> Maybe this is my ignorance speaking, but I don't see any (clean) way 
>> of making client side validation work. How a validation message is 
>> presentated is left up to forms-styling (or whatever you wish to call 
>> it), so you cannot make assumptions about how the validation is 
>> presented.
> Yes, this is an issue that needs addressing.
> However, there may be an answer ..... both Cocoon and Dojo are i18n 
> capable, even though they both use different i18n catalogue formats, 
> Cocoon i18n files could be provided to Dojo via a special transformation.
> Or maybe I am still being naive ; )

I don't know enough about i18n to say.

>> The closest solution I can see is if you created a hook function for 
>> all validation and had the hook function propargate the errors that way.
> Could you expand on what you mean by a hook function?

When you get a client side error, you pass information to a function 
that will indicate what the error is and the field it is associated 
with. This function will then manipulate the HTML to give you the effect 
you want (new class, change in the tabbing, etc...). Maybe this doesn't 
quite work with Dojo, I don't know.

>> That still sounds rather messy and sounds like a duplication of 
>> effort. Also (if the application is fast), it would lead to some bad 
>> UI if some of the validation is done client side some server side.
>> Now, if validation were rewritten in such a way that the hook 
>> functions were called for even server side validation errors, it 
>> might provide a rather neat way of getting around some of the 
>> problems that Ajax CForms throw up as well as reducing duplication. I 
>> really wish I had a better understanding of Dojo so I could fix up 
>> some of the issues related to validation and Ajax.
>>> ATM however, no validation information is output by the form 
>>> generation process. Datatypes are there (which I can initially use) 
>>> but no validation.
>>> So my question is, would someone volunteer to either add the 
>>> definition's validation tags to the output or help work out the 
>>> cleanest approach to adding it?
> thanks
> regards Jeremy

Kamal Bhatt

View raw message