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
