shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: validation messages different for server and client
Date Wed, 17 Jan 2007 02:59:40 GMT
>From: "Joost Schouten" <joost@jsportal.com> 
>
> 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


> 
> 
> 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message