cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: AW: AW: AW: Client-side validation in CForms
Date Mon, 21 Jul 2008 11:44:50 GMT
Hi Chris

Sorry it took me so long to reply.

On 17 Jul 2008, at 16:48, Christofer Dutz wrote:

> Hi Jeremy,
>
> doesn't dojo load a i18n resource for the messages?

It does, but this may be perceived as a problem because CForms users  
expect to supply all of their own i18n messages (and I personally find  
some of dojo's language a bit un-natural).

> I don’t think it should
> be a problem taking over this or getting Dojo to load our i18n  
> resources ...

This is most likely possible, but I have not looked into it yet.

> xml-i18n resources for cocoon would have been really nice for  
> this ... in
> the worst case I think it should be possible (it even might already  
> exist)
> to create a resource-file-generator, that simply converts these nasty
> text-form resource files to neat xml and then translate this to Dojo  
> i18n
> resources with a simple xslt.

Are you confusing java i18n properties-type bundles with Cocoon i18n  
xml message files?
Transforming Cocoon's XML bundles to Dojo's json-based format should  
not be too difficult.

> With the other problems ... well I agree that they might be  
> tricky ... but
> what would the challenge be, if everything was easy? ;-)

Well, we should start with the low hanging fruit :
regExp, min, max, email, mod10, value-count etc.

I was googling for a JavaScript implementation of the XReporter  
expression language, but no luck yet ;)

I have never written an interpreter before :)
But I was thinking about a simple case like this :
<fd:validation>
   <fd:range min="number1 + 1">
     <fd:failmessage>This number should be larger than the first  
number.</fd:failmessage>
   </fd:range>
</fd:validation>

client-side (off the top of my head) :
var min = 0;
try {
   with (this.form) min = eval("number1 + 1")
} catch e {
   // could not evaluate expression
}

so 'number1' gets evaluated in the scope of this.form.

but it quickly gets nasty ......
The languages comparison operator is a single '=' not a double one :(
References to fields can be relative (../fieldname) etc. etc.

> I think the main difference in my approach and the old Cocoon  
> approach is
> not to reinvent the wheel. I never quite understood all the
> double-implemention of widgets. But I have to admit the old Dojo was  
> missing
> quite some stuff and I even had to bugfix quite a lot in the Dojo0.4  
> Stuff.
> At the moment simply using Dojo and providing some very basic  
> JavaScripts
> should be sufficient.

Well one of the problems is that there is a big mismatch between the  
assumptions behind Dojo and CForms.

eg. number fields

Cocoon expects no smarts on the client, so a user would typically have  
a converter for a form value to send a locale-formatted string  
representation of the number to edit to the client :

value: 1234567.89
sends: 1,234,567.89 (en_GB)
        1 234 567,89 (fr_FR)
etc.

Cocoon then expects the formatted value in return.

Dojo however, expects to send and receive un-formatted numbers,  
performing l10n client-side.

This is not impossible to resolve, but it indicates some of the less- 
obvious complexities :)


Thanks for your feedback

regards Jeremy




Mime
View raw message