>From: "Joost Schouten" <[EMAIL PROTECTED]> > > Hi, > > > > When validating, the messages from the server side validation are different > than those for the client side validation. Why does shale not just use the > messages created by commons?
Shale CommonsValidator uses javascript on the client to perform the validation rules (provided by commons). On the server side, shale CommonsValidator uses the commons validation methods to perform the validation (provide by commons). The error message display to the use, if not overridden, is defined in the validation-rules.xml. There has been some recent work to create simple JSF Validators and Converters from commons validator but they don't provide client side script support yet. These validators don't require the XML configs. They are hard wired for a specific type of validation. The CommonsValidator provides a generic mechanism for invoking commons validator client and server logic using the XML config file. The CommonsValidator requires a ValidatorScript component added to the end of the page to look for all of the uses of CommonsValidators within a JSF view. This component adds the client side script. In my opinion, this is where things get complicated and maybe the reason for the recent refactoring effort. One could argue that a validator instances should be responsible for adding client side script in a component framework versus one components that tries to inspect the component tree and act on behalf of all validators. The problem is that JSF validator's doesn't participate in rendering. Only a component can render markup and script. Rich component libraries like tomahawk and trinidad have build in mechanisms to inject javascript into the page. Tomahawk uses a filter to add to the rendered mark-up after JSF rendering. Trinidad uses a document component that creates the root, header and body of the rendered mark-up adding script in the header. So, the new "simple" validators will need a strategy for adding client side script. Client side validation rules become more complex when you are validating data within a UIData family of component. We also have command components that should bypass client side validation when the immediate attribute is turned on. CommonsValidator has some tricks to handle this using runtime renderer decorators. > Or if it uses custom messages, why not > overwrite the messages commons produces so that there is a nice consistency > in what the user gets presented with. Is there a reason for using two > messages, am I missing something? > I'm not sure that I understand what you are getting at here. If you override a message, it should be overridden for both client and server side validation. Could you elaborate? > > > Looking forward to your thoughts. > > > > This is all related to my issues raised in > > http://issues.apache.org/struts/browse/SHALE-373 > > > > Regards, > > Joost Gary > > >
