[
https://issues.apache.org/struts/browse/SHALE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Tsay updated SHALE-356:
----------------------------
Does SHALE-490 (which I provided a proposed fix) encapsulate this issue? I
think we don't need to refactor Common Validator javascript routines except
validatorUtilities.js which Shale Validator provides anyway. But I'm not sure
how to update a <h:message> when I don't know exactly what HTML element it maps
to (could depend on the renderer). The situation with <h:messages> is even
worse ...
> Make it possible to report client side validation errors via DHTML
> manipulations on message elements
> ----------------------------------------------------------------------------------------------------
>
> Key: SHALE-356
> URL: https://issues.apache.org/struts/browse/SHALE-356
> Project: Shale
> Issue Type: Improvement
> Components: Validator
> Reporter: Craig McClanahan
> Fix For: TBD
>
>
> Currently, the Shale Validator implementation reports client side validation
> errors the way that was also used in Struts -- a pop-up alert box. It would
> be very useful to be able, instead, to use DHTML manipulation on the client
> side to update an <h:message> component relevant to the input component(s) in
> error, and/or an <h:messages> component to capture all messages.
> This is likely to depend on some refactoring of the javascript methods
> provided by Commons Validator 1.3.1.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
