On 12/26/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>
> On 12/22/05, JEEVANATHAM P. /BPCRP/INFOTECH/VASHI
> <[EMAIL PROTECTED]> wrote:
>
> > Please let me know about how can we do server side validation in shale.
> Like
> > user validation,
> >
> > when user enters some value that time we need to check with database
> whether
> > that is correct one or not.
>
> This is an interesting question because I have a custom validator in a
> Struts app that does exactly that. Here's what I came up with, though
> I would advise waiting for Craig to comment on whether he intended for
> this to happen. :)
>
> I added another <validator> to validator-rules.xml:
>
> <validator name="lenientDate"
> classname="net.wsmoak.acctmtce.ValidationUtil"
> method="isDate"
> methodParams="java.lang.String"
> msg="errors.lenientDate">
> </validator>
>
> The ValidationUtil.isDate method takes a String and returns true/false
> (boolean).
>
> Left to its own devices, oas.validatorCommonsValidator uses the
> (localized) messages.properties file in org.apache.struts.validator
> (inside shale-core.jar). Since I know the Servlet spec requires that
> things in WEB-INF/classes be loaded before things in WEB-INF/lib, I
> extracted the messages.properties file from shale-core.jar, to
> WEB-INF/classes/org/apache/shale/validator/, and added my new message
> to it.
>
> In the JSP:
>
> <h:outputText value="#{messages['prompt.effectiveDate']}"/>
> <h:inputText id="effectiveDate"
> value="#{effectiveDate}">
> <s:commonsValidator
> type="lenientDate"
> server="true"
> client="false"/>
> </h:inputText>
> <h:message for="effectiveDate" styleClass="errors"/>
>
> At least for simple validations, it appears to work fine. It has
> advantages over all of the 'pure JSF' methods that I investigated-- I
> certainly don't want to write a custom Validator, and even a simple
> method binding in the 'validator' attribute of a component means
> you're responsible for formatting the error message. But if you need
> more/different parameters than the ones <s:commonsValidator> provides,
> then I do think you'd need to write your own custom JSF Validator and
> tag, or possibly extend the ones in Shale.
>
> I'm going to open a couple of enhancement tickets for things like
> including validator-rules.xml in shale-core.jar so that you don't have
> to find and include a copy in your webapp to use the provided
> validators, and making the the name and location of both the messages
> and the validation rules file(s) configurable. Other ideas and
> suggestions are welcome!
Wendy's technique works fine, although it would be nice if Commons Validator
would read more than one resource bundle file without needing to extract it
and add the file to WEB-INF/classes yourself (your reading of the ordering
requirements is correct).
As for doing things in pure JSF validators (either a separate Validator
implementation or as a validation method pointed to with a method binding),
Shale does offer some help for formatting the messages. There are two
classes in the org.apache.shale.util package for this purpose:
* LoadBundle - Loads a resource bundle and exposes it as a Map (similar
in spirit to what the <f:loadBundle> tag does in a page, but making the
messages available programatically as well.
* Messages - Utillity for getting locale-specific messages from a set of
resource bundles, including parameter substitution, similar to what
Struts Action Framework provides with MessageResources.
Both of these classes are pure POJOs designed to be configured with setter
injection, so it is very easy to configure them as managed beans (normally
in application scope). See the class level javadocs of these two classes
for examples.
HTH,
> --
> Wendy
> http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleValidator
Craig
