cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: Client-side validation in CForms
Date Fri, 11 Jul 2008 11:31:18 GMT

On 11 Jul 2008, at 00:51, Kamal Bhatt wrote:

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

Yes, Dojo does work like this.
Dojo-supplied fields that may either be required or have validation  
rules have built-in ways to display this status.

Either via Dojo's built-in i18n, or via attributes : @promptMessage  
and @errorMessage. Both of which could be populated with i18n strings  
from Cocoon.


>
>>
>>> 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



Mime
View raw message