Re: Client-side validation - enhance to match server-side
Does anyone have any feedback on this patch? I don't expect it is perfect or complete, but I'd like to understand if this is the approach you'd expect for implementing this feature. https://issues.apache.org/jira/browse/ADFFACES-391 On 3/16/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, I've posted an initial patch so client-side validation matches server-side here: https://issues.apache.org/jira/browse/ADFFACES-391 Feedback gratefully received. Description: Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION /param-name param-valuetrue/param-value /context-param [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ] Danny Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson [16/Mar/07 08:59 AM] Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name param-valuetrue/param-value /context-param On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
Sorry - I've been wanting to have a look at it, but been generally swamped. Hopefully soon... -- Adam On 4/20/07, Danny Robinson [EMAIL PROTECTED] wrote: Does anyone have any feedback on this patch? I don't expect it is perfect or complete, but I'd like to understand if this is the approach you'd expect for implementing this feature. https://issues.apache.org/jira/browse/ADFFACES-391 On 3/16/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, I've posted an initial patch so client-side validation matches server-side here: https://issues.apache.org/jira/browse/ADFFACES-391 Feedback gratefully received. Description: Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION /param-name param-valuetrue/param-value /context-param [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ] Danny Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson [16/Mar/07 08:59 AM] Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name param-valuetrue/param-value /context-param On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
OK, I've posted an initial patch so client-side validation matches server-side here: https://issues.apache.org/jira/browse/ADFFACES-391 Feedback gratefully received. Description: Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION /param-name param-valuetrue/param-value /context-param [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ] Danny Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson [16/Mar/07 08:59 AM] Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name param-valuetrue/param-value /context-param On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete
Re: Client-side validation - enhance to match server-side
may be you can use GWT compiler for client side validation as well, it is also under Apache 2 license. On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Arash Rajaeeyan
Re: Client-side validation - enhance to match server-side
are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Client-side validation - enhance to match server-side
I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Client-side validation - enhance to match server-side
I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Client-side validation - enhance to match server-side
the difference is with GWT, user can write java code for client side validation instead of JS. they can compile it with their own Java IDE. but I also agree that adding another dependency to MyFaces is not good, specially dependency to such a big project. On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
