Re: AW: AW: AW: AW: Client-side validation in CForms
Hi Chris On 22 Jul 2008, at 21:17, Christofer Dutz wrote: 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. OK. IMHO i18n is well worth getting your head around . very powerful . I use it for most if not all static strings in my projects, regardless of whether I want to make it work in multiple languages. 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. That would be very cool ! 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). Sounds like an interesting approach. There is also the standard form elements Array and the dojo Widget registry to help find stuff. One problem will be that the CForms model is a hierarchy and is ID'd and traversed as one, while on the client it is effectively flat. 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. I agree, the sax-generation of validation info needs to be done first. There is quite a lot that can be done, without an expression interpreter. Many thanks for your interest regards Jeremy
AW: AW: AW: AW: Client-side validation in CForms
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:failmessageThis 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
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 don’t 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:failmessageThis 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
AW: AW: AW: Client-side validation in CForms
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:hintPlease name your datasource/fd:hint
fd:helpdivThis is breally/b helpful advice!!/div/fd:help
fd:datatype base=string/
fd:validation
fd:regexp pattern=C.*
fd:failmessageSorry, 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: 1, 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/
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:hintPlease name your datasource/fd:hint
fd:helpdivThis is breally/b helpful advice!!/div/fd:help
fd:datatype base=string/
fd:validation
fd:regexp pattern=C.*
fd:failmessageSorry, 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: 1, 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/
AW: AW: Client-side validation in CForms
=fi:repeater-size input type=hidden name=[EMAIL PROTECTED] value=[EMAIL PROTECTED]/ /xsl:template !-- Defaults -- xsl:template match=@*|node() priority=-1 mode=forms-header xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template xsl:template match=fi:label/ /xsl:stylesheet -Ursprüngliche Nachricht- Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] Gesendet: Montag, 14. Juli 2008 12:41 An: dev@cocoon.apache.org Betreff: Re: AW: Client-side validation in CForms Hi Christofer On 13 Jul 2008, at 13:13, Christofer Dutz wrote: When I was working on my first attempts to do exactly what you are trying to do (CForms using dojo 1.1 and client side validation), I ran into exactly the same problem as you did. I too think it would be easily possible to implement client and server-side validation using dojo. Even if it would not be possible to implement all. Unfortunately the fi-output is hard-coded into the widget class implementation and no validation information is sent. Making client- side validation work, it would make it necessary to patch every single Widget class to output this validation-data, but should be easy to accomplish. I stopped my work on this, since I had doubt's anyone would be interested in a feature like this and the thought of having to maintain patches for so many classes let me drop that idea. I had a look as well and did not fancy ploughing in to the code to add this right now, as I have so much else to do before I can release the client-side stuff (hence asking for volunteers ) What I am working on in the meantime is using the (existing) fi:datatype base=string|integer|long|double|float|decimal/ tags to perform basic datatype validation on the client. My hope is that adding support for this now, will make it easier to add fuller validation client-side in the future. BTW. Christofer, I attempted to contact you earlier about the private work you said you had been doing on Dojo 1.1, to see if I could roll it into my work. If you are interested in contributing, please contact me off-list. Many thanks regards Jeremy -Ursprüngliche Nachricht- Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Juli 2008 17:17 An: dev@cocoon.apache.org Betreff: Client-side validation in CForms Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? Many thanks regards Jeremy
