Re: custom server side validation in shale
On 12/26/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > I'm going to open a couple of enhancement tickets ... These were: http://issues.apache.org/bugzilla/show_bug.cgi?id=38042 http://issues.apache.org/bugzilla/show_bug.cgi?id=38044 The first one moves validator-rules.xml into shale-core.jar so that you don't have to keep a copy of it in your webapp, and the second one makes it easier to add custom validation by allowing you to configure a list of validation rules files in web.xml. The documentation lives here at the moment: http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleValidator -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom server side validation in shale
On 12/26/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > 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 I think it already does. :) Looking at CommonsValidator.getErrorMessage again, it first looks in the application's message bundle, and then looks in oas.validator/messages.properties. Assuming you've defined your message bundle in faces-config.xml: ApplicationResources ... You can add your custom messages to (in this case) WEB-INF/classes/ApplicationResources.properties, and leave messages.properties alone. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom server side validation in shale
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 to validator-rules.xml:
>
> classname="net.wsmoak.acctmtce.ValidationUtil"
> method="isDate"
> methodParams="java.lang.String"
> msg="errors.lenientDate">
>
>
> 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:
>
>
>value="#{effectiveDate}">
> type="lenientDate"
> server="true"
> client="false"/>
>
>
>
> 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 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 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
Re: custom server side validation in shale
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 to validator-rules.xml: 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: 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 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! HTH, -- Wendy http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleValidator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
custom server side validation in shale
Hi all, 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. If not that will through a alert not message on the screen. Regards, JEEVANANTHAM PARAMASAMY, Software Engineer, 3i - INFOTECH Limited, Alwarpet, Chennai - 600018. Phone: 044 24678000 extn:418 Cell no: 09840933967 -- Greetings! ICICI Infotech is now 3i Infotech. The e-mail addresses of the company's employees have been changed to @3i-infotech.com. You are requested to take note of this new e-mail ID and make use of the same in future "This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that 3i Infotech or its subsidiaries and associated companies, (collectively "3i Infotech"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of 3i Infotech. Before opening any attachments please check them for viruses and defects."
