Ted Husted wrote:
>
> "Sobkowski, Andrej" wrote:
> > What if the
> > validation on the same bean is different depending on the app context? It
> > wouldn't be "clean" (for lack of better word) to consider both validations
> > inside the bean itself (validate())... hence the advantage of having
> > separate validation processes on the same bean (related to different app
> > contexts i.e. different actions). Am I missing the point?
>
> That would be part of a second-level validation, along with "does a
> password and username match?".
>
> A first level validation would be whether a username and password were
> given, and whether confirmation passwords match each other. This is best
> handled by the ActionForm directly.
>
[ snip ]
If it helps any, the yardstick we used for deciding where
validation goes was based on how we might do things if we were
programming a real UI. For example, if it was the kind of validation
that a swing control would do (not the model but the control) then
we'd consider that safe to do in web-land. Anything else is business
layer. (The new formatted text field class is a good example of a
more complicated control that can deal with more than just strings.)
All said and done, this pretty much leaves validation associated with
type conversions... for the truely broad object-oriented sense of the
word type, i.e.: a user name is not just a String but is its own type
with its own restrictions that will always be true. For convenience
we never model these things as String subclasses, but technically they
are their own types.
It is for exactly this reason that my own validation/conversion code
has abstracted "type" into its own class separate from "Class". It
lets me tag properties as different "types" without having to create a
new Java .class every time... but that's another story.
-Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
