Ron, have you looked at: http://myfaces.apache.org/tomahawk/validateRegExpr.html
-Matthias > -----Original Message----- > From: Romero, Ron [mailto:[EMAIL PROTECTED] > Sent: Friday, August 12, 2005 6:10 PM > To: Struts Developers List > Subject: New Shale Regex Validation Tag > > > I'm working with the Shale Validator. I would like a new, simpler > "regexValidator" tag that better supports my situation (and hopefully > supports other people's situation). > > > BACKGROUND > ========== > > We're writing a JSF Portlet app. The *only* part of Shale that we're > using is the Validator. We're using only the Regex package, and we > always want client-side and server-side validation. > > We will provide the regexes for the entire project in a > single place, so > that, for example, run-of-the-mill developers don't have to decide how > many and which characters are allowed in a first name. And so we can > change the firstName regex in a single place and effect the > entire app. > > Our current approach is to put all of the regexes into a > message bundle, > and instruct users to use the message bundle to specify their regular > expression. So current usage looks like this: > > <s:commonsValidator arg="#{msg.firstName}" > server="true" client="true" > type="mask" mask="#{regex.firstName}" /> > > > THE NEW REGEX TAG > ================= > > I would like to have a general tag where the developer specifies the > type of field, and the field looks up the regex needed, and possibly > also whether verification should be client-side or server-side or both > and possibly also the arg to use in the error message. Using this I > would like to the tag to be very simple to use. The above usage would > look like this: > > <s:regexValidator type="firstName" /> > > Validator masks and information would be stored in a > configuration file, > maybe "validator-regexes.xml" > > > WHAT TO DO > ========== > > This would involve writing a new custom tag. It would look up the > relevant information, and then call Shale commonsValidator with that > information. This would all be in Shale Validator; we don't need any > new functionality from commons-validator. > > I may be able to write the code for this, or primarily write the code. > And I can definitely test, debug, and suggest. But, frankly, it's not > worth my trouble to work on this unless it'll get back into Shale > Validator. > > So, what do you think? Is this worthwhile? Any major holes? Is this > something Shale Validator should be doing? Should I enter a bugzilla > enhancement request? > > > > Thanks, > > Ron Romero > Texas ACCESS Alliance > Work 512-732-5827 > AIM: ronzromero > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
