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: Client-side validation in CForms
Date Wed, 16 Jul 2008 10:45:20 GMT
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 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

<snip/>




Mime
View raw message