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/
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
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
AW: Client-side validation in CForms
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. Chris -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
Re: Client-side validation in CForms
On 11 Jul 2008, at 00:51, Kamal Bhatt wrote: Jeremy Quinn wrote: Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: 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) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) I don't know enough about i18n to say. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? When you get a client side error, you pass information to a function that will indicate what the error is and the field it is associated with. This function will then manipulate the HTML to give you the effect you want (new class, change in the tabbing, etc...). Maybe this doesn't quite work with Dojo, I don't know. Yes, Dojo does work like this. Dojo-supplied fields that may either be required or have validation rules have built-in ways to display this status. Either via Dojo's built-in i18n, or via attributes : @promptMessage and @errorMessage. Both of which could be populated with i18n strings from Cocoon. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. 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? Thanks regards Jeremy
Re: Client-side validation in CForms
Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: 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) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. 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? thanks regards Jeremy
Re: Client-side validation in CForms
Jeremy Quinn wrote: Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: 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) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) I don't know enough about i18n to say. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? When you get a client side error, you pass information to a function that will indicate what the error is and the field it is associated with. This function will then manipulate the HTML to give you the effect you want (new class, change in the tabbing, etc...). Maybe this doesn't quite work with Dojo, I don't know. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. 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? thanks regards Jeremy -- Kamal Bhatt
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
Re: Client-side validation in CForms
Jeremy Quinn wrote: 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) Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. 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 -- Kamal Bhatt
[jira] Updated: (COCOON-1360) [patch] client side validation for CForms
[ http://issues.apache.org/jira/browse/COCOON-1360?page=all ] David Crossley updated COCOON-1360: --- Bugzilla Id: (was: 32419) Other Info: [Patch available] Description: This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field was: This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field [patch] client side validation for CForms - Key: COCOON-1360 URL: http://issues.apache.org/jira/browse/COCOON-1360 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Luca Garulli Assignee: Cocoon Developers Team Priority: Minor Attachments: clientside-validation.js, clientside-validation.js, clientside-validation.js, clientside-validation.xsl, clientside-validation.xsl, clientside-validation.xsl, date.js, readme.txt This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13674|0 |1 is obsolete|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13675|0 |1 is obsolete|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 18:01 --- Created an attachment (id=14487) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14487action=view) JS functions New version with the following improvements: - I18N for all error messages - support for min/max/exact length and range constraints - support for regexp contraints (specify a pattern to match) - immediate check for type field: you cannot enter non-numeric char in a numeric field Enjoy ;-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 18:03 --- Created an attachment (id=14488) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14488action=view) XSL transformer (server-side) to enrich the XML generated by CForms transformer New version with the following improvements: - I18N for all error messages - support for min/max/exact length and range constraints - support for regexp contraints (specify a pattern to match) - immediate check for type field: you cannot enter non-numeric char in a numeric field Enjoy ;-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Client side validation for CForms
Hi, I've committed a new version of client-side validation. New version with the following improvements: - I18N for all error messages - support for min/max/exact length and range constraints - support for regexp contraints (specify a pattern to match) - immediate check for type field: you cannot enter non-numeric char in a numeric field Download new attachments below: http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 bye, Luca Garulli www.Pro-Netics.com (member of Orixo.com - The XML business alliance) OrienTechnologies.com - Light ODBMS, All in one JDO solution On Mon, 7 Feb 2005 15:17:31 +0100, Luca Garulli [EMAIL PROTECTED] wrote: Hi Philippe, I changed the client side validation a lot in these days to support much more things. I'll post it ASAP in bugzilla, please check tomorrow ;-) bye, Luca Garulli www.Pro-Netics.com (member of Orixo.com - The XML business alliance) OrienTechnologies.com - Light ODBMS, All in one JDO solution On Sun, 06 Feb 2005 20:58:39 +0800, Philippe Guillard [EMAIL PROTECTED] wrote: Hi all, My idea is to systematically use server-side validation as it is necessary, + some client-side to be confortable for the user. I used the (great) patch found in http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. Anyway i get trouble when i think about string lenght limitation. The main hack in this patch is this: xsl:for-each select=..//fi:field validation_register_widget( 'xsl:value-of select=@id/', xsl:if test=@required='true'true/xsl:if, 'xsl:value-of select=fi:datatype/@type/', 'xsl:value-of select=fi:datatype/fi:convertor/@pattern/' ); /xsl:for-each Problem: fi:validation/fd:length/@max seems not to be disponible in output of the CForm transformer. that part is a big one! So i ask if somebody has another idea/did it/ or can give me hints to do it. Regards, Phil
Re: Client side validation for CForms
Hi Philippe, I changed the client side validation a lot in these days to support much more things. I'll post it ASAP in bugzilla, please check tomorrow ;-) bye, Luca Garulli www.Pro-Netics.com (member of Orixo.com - The XML business alliance) OrienTechnologies.com - Light ODBMS, All in one JDO solution On Sun, 06 Feb 2005 20:58:39 +0800, Philippe Guillard [EMAIL PROTECTED] wrote: Hi all, My idea is to systematically use server-side validation as it is necessary, + some client-side to be confortable for the user. I used the (great) patch found in http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. Anyway i get trouble when i think about string lenght limitation. The main hack in this patch is this: xsl:for-each select=..//fi:field validation_register_widget( 'xsl:value-of select=@id/', xsl:if test=@required='true'true/xsl:if, 'xsl:value-of select=fi:datatype/@type/', 'xsl:value-of select=fi:datatype/fi:convertor/@pattern/' ); /xsl:for-each Problem: fi:validation/fd:length/@max seems not to be disponible in output of the CForm transformer. that part is a big one! So i ask if somebody has another idea/did it/ or can give me hints to do it. Regards, Phil
Client side validation for CForms
Hi all, My idea is to systematically use server-side validation as it is necessary, + some client-side to be confortable for the user. I used the (great) patch found in http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. Anyway i get trouble when i think about string lenght limitation. The main hack in this patch is this: xsl:for-each select=..//fi:field validation_register_widget( 'xsl:value-of select=@id/', xsl:if test=@required='true'true/xsl:if, 'xsl:value-of select=fi:datatype/@type/', 'xsl:value-of select=fi:datatype/fi:convertor/@pattern/' ); /xsl:for-each Problem: fi:validation/fd:length/@max seems not to be disponible in output of the CForm transformer. that part is a big one! So i ask if somebody has another idea/did it/ or can give me hints to do it. Regards, Phil
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 18:54 --- I tried to get validation going with the above files, but had to tweak the js a little. I'm just pasting this patch inline because there's not much to it. 26c26,28 var field = validation_form.elements[ iName ]; --- //var field = validation_form.elements[ iName ]; // For some reason firefox doesn't like the above statement. var field = document.forms[0].elements[ iName ]; 75,76c77,79 var dateType = validation_widgets[iWidget]; if( datatype == integer || iDatatype == long ) --- var datatype = validation_widgets[iWidget]; alert(datatype); if( datatype == integer || datatype == long ) 82c85 else if( datatype == double || iDatatype == decimal ) --- else if( datatype == double || datatype == decimal ) 157c160 return; --- return false; 159c162 } \ No newline at end of file --- } -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13565|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 21:52 --- Created an attachment (id=13674) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13674action=view) JS functions Copied from bug #32517. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13566|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 21:54 --- Created an attachment (id=13675) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13675action=view) XSL transformer (server-side) to enrich the XML generated by CForms transformer Copied from bug #32517. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13674|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO|32517 | nThis|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 21:55 --- *** Bug 32517 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32419.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32419
--- Additional Comments From [EMAIL PROTECTED] 2004-12-03 18:27 ---
(From update of attachment 13566)
?xml version=1.0?
!--
clientside-validation
@author Luca Garulli ([EMAIL PROTECTED])
--
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fi=http://apache.org/cocoon/forms/1.0#instance;
xsl:param name=modeform/xsl:param
xsl:template match=page
page
xsl:apply-templates select=head/
xsl:apply-templates select=body/
/page
/xsl:template
xsl:template match=head
head
script language=javascript src=/js/date.js/
script language=javascript src=/js/clientside-validation.js/
script language=javascript
!-- REGISTER ALL WIDGETS --
function validation_init()
{
xsl:for-each select=..//fi:field
validation_register_widget( 'xsl:value-of select=@id/',
xsl:if
test=@required='true'true/xsl:if,
'xsl:value-of
select=fi:datatype/@type/',
'xsl:value-of
select=fi:datatype/fi:convertor/@pattern/' );
/xsl:for-each
}
validation_init();
/script
xsl:apply-templates/
/head
/xsl:template
xsl:template match=body
xsl:copy-of select=./
/xsl:template
!--xsl:template match=fi:field
xsl:if test=$mode='field'
fi:field
fi:styling onChange=javascript:validate_xsl:value-of
select=@id/();/
/fi:field
/xsl:if
/xsl:template--
/xsl:stylesheet
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||32517 nThis|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] New: - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 Summary: [patch] client side validation for CForms Product: Cocoon 2 Version: 2.1.6 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: CocoonForms AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2004-11-28 12:12 --- Created an attachment (id=13565) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13565action=view) JS functions -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2004-11-28 12:13 --- Created an attachment (id=13566) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13566action=view) XSL transformer (server-side) to enrich the XML generated by CForms transformer -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2004-11-28 12:15 --- Created an attachment (id=13567) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13567action=view) Matt Kruse library for number and date checking There already exists in sample blocks. I've posted it here to include in CForms... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32419] - [patch] client side validation for CForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32419 --- Additional Comments From [EMAIL PROTECTED] 2004-11-28 12:16 --- Created an attachment (id=13568) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13568action=view) short description about usage -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
