cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christofer Dutz" <>
Subject AW: AW: AW: AW: Client-side validation in CForms
Date Tue, 22 Jul 2008 20:17:42 GMT
Hi ... well I never really used the I18N Stuff, I have to admit. 
Every time I got in contact with it (currently using Cocoon 2.1.10) I
thought they were text files and no Xml files.

Regarding your Expression-Interpreter. I do have quite some experience with
parsers and interpreters, so maybe this could be a part that I could help
you with. 

If we think of all Form elements as dojo widgets, we could use the dojo
query functions for finding elements, since it's a lot easier navigating in
the widget hierarchy than in the html page (dojo.byId vs. dijit.byId). 

Unfortunately I am currently struggling with some issues of my current
cocoon project, but I think I will have them solved in the next few days. I
would gladly help with these client side validators, but I would rather
suggest adjusting the Server Side Sax-Generation to output the needed
information first ... without this, all client side stuff is useless, since
we can't get the validator rules to our cforms-xslt.


-----Urspr√ľngliche Nachricht-----
Von: Jeremy Quinn [] 
Gesendet: Montag, 21. Juli 2008 13:45
Betreff: Re: AW: AW: AW: Client-side validation in CForms

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:range min="number1 + 1">
     <fd:failmessage>This number should be larger than the first  

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)

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

View raw message