Hi Jeremy, doesn't dojo load a i18n resource for the messages? I dont think it should be a problem taking over this or getting Dojo to load our i18n resources ... 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.
With the other problems ... well I agree that they might be tricky ... but what would the challenge be, if everything was easy? ;-) 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. Chris -----Ursprüngliche Nachricht----- Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2008 12:45 An: dev@cocoon.apache.org Betreff: Re: AW: AW: Client-side validation in CForms Hi Chris Thanks for this, it should speed me up a bit, I hope : ) Simple client-side validation based on datatype is working here. Dojo's constraints and filters are working too, so as a proof of concept it is working well. One issue(?): when a field is invalid (while you are typing) you will see one of Dojo's generic i18n error messages until you have submitted the bad data to Cocoon, only then will you see the cform's error messages. Not sure if there will ever be a workaround for this ... So currently, the main problem is that you'd have to specify the same validation twice ...... model : <fd:field id="name" required="true"> <fd:hint>Please name your datasource</fd:hint> <fd:help><div>This is <b>really</b> helpful advice!!</div></fd:help> <fd:datatype base="string"/> <fd:validation> <fd:regexp pattern="C.*"> <fd:failmessage>Sorry, the PMC really does insist the name should begin with the letter 'C'.</fd:failmessage> </fd:regexp> </fd:validation> </fd:field> template (eg. with filters applied on the client) : <ft:widget id="name"> <fi:styling propercase="true" trim="true" regExp="^C.*"/> </ft:widget> Obviously it is ghastly to specify the same validation twice, so the next sensible step IMHO is to get the validation info generated out to the template in a form that can be processed by xslt into appropriate constraints for dojo. eg: {min: 10, max: 10000, places: 0} etc. The main problem is going to be handling expressions ..... specially stuff that points to other objects : <fd:validation> <fd:range min="number1 + 1"> These are the constraints for Number types : pattern: String? override [formatting pattern] (http://www.unicode.org/reports/tr35/#Number_Format_Patterns ) with this string type: String? choose a format type based on the locale from the following: decimal, scientific, percent, currency. decimal by default. places: Number? fixed number of decimal places to show. This overrides any information in the provided pattern. round: Number? 5 rounds to nearest .5; 0 rounds to nearest whole (default). -1 means don't round. currency: String? an [ISO4217](http://en.wikipedia.org/wiki/ISO_4217) currency code, a three letter sequence like "USD" symbol: String? localized currency symbol locale: String? override the locale used to determine formatting rules The constraints for Ranges : min: Number? the lowest value allowed max: Number? the highest number allowed Hopefully we can pull out a usable subset of cforms validation and present it to the client-side. I'll let you guys mull it over for a while :) Thanks again regards Jeremy On 14 Jul 2008, at 14:45, Christofer Dutz wrote: <snip/> > I think generating the validation-output needed for client side- > validation > shouldn't be a big problem, since its the same for almost all > widgets the > class having to be patched should be the simple Widget base-classes. > I would > volunteer implementing it, but only if it is really wanted. > > Chris <snip/>
