cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christofer Dutz" <>
Subject AW: AW: AW: Client-side validation in CForms
Date Thu, 17 Jul 2008 15:48:00 GMT
Hi Jeremy,

doesn't dojo load a i18n resource for the messages? I don’t 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.


-----Ursprüngliche Nachricht-----
Von: Jeremy Quinn [] 
Gesendet: Mittwoch, 16. Juli 2008 12:45
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:regexp pattern="C.*">
         <fd:failmessage>Sorry, the PMC really does insist the name  
should begin with the letter 'C'.</fd:failmessage>

template (eg. with filters applied on the client) :

<ft:widget id="name">
   <fi:styling propercase="true" trim="true" regExp="^C.*"/>

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:range min="number1 + 1">

These are the constraints for Number types :
pattern: String?
	override [formatting pattern]
) 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]( 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:


> I think generating the validation-output needed for client side- 
> validation
> shouldn't be a big problem, since it’s 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


View raw message