I don't think there would be anything wrong with your
idea, but I think it is a little more flexible keeping
the validation separate from the ActionForm. I
started working on a validation framework, but I put
the info in an xml file. I would rather change a
value in an xml file than having to recompile my code.
* It makes the validation rules more accessible to
less technical people. One day the XML might tie into
a JSP editing tool to provide easy access and editing
of the validation rules.
* I think it makes it easier to generate JavaScript
that has the same information you pass into the java
validation method.
* It let's you decouple the actual code that performs
a validation from the validation. You can just say a
field is required and if you redefine what
class/method performs the required validation you
won't need to change anything else. (not that you
couldn't do this with an interface you've created too)
* When the exception/validation happens in the setter,
you can't do things that depend on other fields. Like
this field is required only if another field is filled
in.
These are a couple of thoughts off the top of my head.
Here is a link to what I've done so far.
http://home.earthlink.net/~dwinterfeldt
David
--- "Cook, Levi" <[EMAIL PROTECTED]> wrote:
> I'm guessing my aforementioned ideas on validation
> fall into one of the
> following categories:
>
> 1. its was a really bad idea, not worth commenting
> or elaborating on
> 2. i didn't provide a clearly articulated idea to
> review
> 3. they're fine and everyone's really busy, and
> i'm impatient
>
> I'll assume its items mostly 3, and will apologize
> in advance for seeming
> impatient.
>
> However, does anyone care to comment on its
> viability??
> Should I proceed with making a more formal
> proposal??
> Does this miss the mark totally for framework based
> validation??
>
> If I failed on item 2, what's missing?? (scope,
> applicability, etc..)
>
> Sorry to be a bug, I truly appreciate everyone's
> time and effort with
> Struts.
>
> -- Levi
>
> > -----Original Message-----
> > From: Levi Cook [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 19, 2001 11:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: server-side, java-based validation rules
> for struts..
> >
> >
> > I believe its well established that Struts would
> benefit from a good
> > validation framework (duh, right?). While there
> are a number of
> > really good ideas floating around, some seem to be
> introducing
> > unnecessary complexity (IMHO, of course)
> >
> > Getting to the point, I think constrained
> properties from the
> > JavaBeans spec. provides a built in, flexible
> foundation for
> > struts invoked validation.
> >
>
(http://java.sun.com/products/javabeans/docs/spec.html)
> >
> > key advantages:
> > * support is provided by the standard java.beans
> package
> > * it doesn't require learning anything
> proprietary (even though
> > other solutions are very cool :)
> > * its conceptually simple; ie. before accepting
> a new value,
> > the bean/ActionForm's setter method(s) ensures
> its accepted by
> > all registered listeners before commiting the
> value
> > (java.bean.VetoableChangeListenter).
> > * and finally, its wide open for extension (key
> since we can't
> > predict all validation scenario's, right?)
> >
> > I also believe that integration with Struts could
> be pretty straight
> > forward. In a nutshell, we could make 2
> modifications ActionServlet:
> >
> > 1. Make it responsible for registering
> "change-listeners"
> > 2. Make it handle PropertyVetoException(s)
> thrown by setter methods
> > (primarily by turning them into ActionErrors)
> >
> > Prior to making a "formal" proposal for this, I
> thought it might be
> > useful to consider the attached code fragments:
> >
> > Then again, maybe I'm way off and should be
> ignored- If I am,
> > let me know..
> >
> > Regards,
> > Levi Cook
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
