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/>
