--- Ted Husted <[EMAIL PROTECTED]> wrote:
> David Winterfeldt wrote:
> > Nic Hobbs and I have both volunteered for the
> Standard
> > (Server Side) Validations and Ted Husted, Nic
> Hobbs,
> > Spencer Smith and I have volunteered for the
> Client
> > Validations (JavaScript). Ted has been using a
> > validation framework I've done on a project
>
> I'm real happy with David's framework and would +1
> it as Struts 1.1
> component (I'm already touting it as a standard
> option in the new Strut
> by Strut piece.)
thanks
>
> One thing I had to do myself was to add some
> validations and
> transformations that were outside the scope of
> regular expressions. For
> example, forcing a string property to uppercase,
> validating the general
> format of a credit card number, checking that a date
> is current. Of
> course, I deployed these in both Javascript and then
> client-side as part
> of the ActionForm validation.
I think it would be good to get a list together of all
the basic validations we would want to do. I normally
want to do validations based on the database field the
bean field corresponds to and basic things like phone
numbers, zip codes, etc. Is the date validation you
made i18n?
> My only thought would be whether we want
> to provide support for extending the package for
> custom, non-Regex
> validations, and perhaps transformations. If so,
> that leads to the idea
> of whether we might want a seperate helper package
> that could handle the
> grunt-work and plug into the Validator (see also
> "Proposed feature: Bean
> propertytransformations").
>
Non-regex validations can easily be added. What did
you have in mind exactly? Do you mean date, credit
cards, etc? I also thought that we could make
constants for things like phone numbers, zip, social
security, etc., but you could override them if you
wanted to.
I like the idea of a transformation package a lot. I
think it would be good if it were separate. I've read
the other thread. If all the fields for a form were
specified in the XML file even if they didn't need to
be validated, the "XML --> ActionForm Code Generator"
on the To Do list could use the validation.xml to
generate the ActionForm (of course it would have to be
smart enough to handle nested properties). We could
also have a type attribute for a field that could be
set to defined types like byte, int, etc. It would be
nice then if there was a matching validation to make
sure it was a byte and then the transformation to
convert it to a byte. I think it is good to keep the
ActionForm and the bean with get/set handling
something other than String separate. There could be
a mapping between the ActionForm and the other bean in
the xml file.
David
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
