At 09:16 AM 2/16/01 +0100, Michael Gerdau wrote:
>I'm not quite sure about the difference between (2) and (3).
Sorry, I should have been more clear.
In option (2), the bean-generation tool would read validation rules from
the XML definition of the beans and generate code to perform the necessary
validation. The validation code would be built in to the bean itself.
In option (3), the bean-generation tool would always generate the same
validate() method. That method would read an XML definition of the
validation rules at run time, and perform the necessary validation. This is
what David Winterfeldt's Validator does.
>I don't see why "must match 'mm/dd/yy'" shouldn't be part of this
>automatically created validator either. And that could as well check
>wether the date entered actually is a valid one (e.g. no 31. Apr, 29 Feb
>outside leapyears etc.). After all that basically implements the
>requirement 'must be a date' which would be in line with
>'must be an integer'.
I guess I picked a poor example. What I meant was that built-in validation
might be restricted to simple stuff like "Does Integer.parseInt succeed?"
while validation that is domain-specific could be left to an external
specification.
As an aside, validation of dates brings up the issue of introducing the
locale to the validation scheme.
>And while I'm at it it might come handy if we could somehow describe
>some rules which define valid patterns for other types as well.
Regular expressions are an obvious candidate here. The Validator uses the
Jakarta Regexp package for this.
>Last not least I easily can envision the need for dynamically adding
>constraint derived from other attributes, e.g. for floats (monetary
>values) to require they have no more than 2 fractional digits, being
>lower than a certain upper value (e.g. an account balance), defining
>relationships between entered values (e.g. one being a multiple of the
>other or being between two others etc) and possibly quite a few more
>such things.
Yes, there are many options to consider in the validation "big picture". At
some point, especially when you get into relationships between fields, we
have to ask ourselves whether it's worth trying to write a specification
versus just writing the code.
>Since I'm already in 'wish mode':
>a generic 'currency module' possibly combined with an 'interest module'
>would be rather nice as well. If there is more demand for such things
>I'd be happy to help here as I'm currently working on porting something
>like that from C/C++ to Java anyway. Knowing others requirements would
>help making it of general useability.
I'll leave that to the generic validation discussion, which is in full
swing over on struts-user right now. What I'd really like to pursue in this
thread is how to address validation within the context of automatically
generating form beans.
>Just my thoughts, best,
>Michael
Thanks!
--
Martin Cooper
Tumbleweed Communications
