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