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. Chris -----Ursprüngliche Nachricht----- Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] Gesendet: Montag, 21. Juli 2008 13:45 An: dev@cocoon.apache.org 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 dont 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
