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
