ValidatingActionForm

["Nestel, Frank" <fr...@coi.de>]

Sitting and reading, I feel struts seems to go in 
exactly the direction I'll need. Great. I'll delete
my projects start as long as possible, to catch enough
stable stuff of struts as possible.

Not sure if I missed s.th. with the ValidatingActionForm.
Looks to me, that a parameterless validate() might be not
enough. In the concrete example of a registration like in 
the example, I endet up with a validate() which hat to 
differentiate between a first time log in (where entering
a username was OK) and a later edit of user data (where
the username was taboo, since it was kind of a database id).
Also the bean might not know that it is part of a special 
database, but it might need to, to verify that a new username
does not allready exist in that database.

It's clear that all processing (new/edit and database check
back) could be done within the bean, its more a design thing:

* Should we end up with a bean which covers all those cases.
* Should one use a whole family of beans which have the same
  setters and getters, but different validate()s.
* Should a ValidatingActionForm care about the special cases,
  leaving only basic validation to the bean?

Since the framework is still moving those alternatives make
me kind of clueless :-)

> -----Ursprüngliche Nachricht-----
> Von: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Gesendet am: Donnerstag, 15. Juni 2000 19:28
> An: struts-dev@jakarta.apache.org
> Betreff: Re: ErrorsTag
> 
> "Hutchison, Jeff" wrote:
> 
> > On Thu, 15 Jun 2000, Craig R. McClanahan wrote:
> >
> > > > "Hutchison, Jeff" wrote:
> > > > What I've got in the works:
> > > >
> > > > ValidatingActionForm - new interface
> > > > ValidatingActionFormBase - new abstract basic 
> implementation of above
> > > > ActionMapping - added inputForm property
> > > > ActionMappingBase - added inputForm property implementation
> > > > ActionServlet - modify perform to check for instanceof
> > > > ValidatingActionForm
> > > >
> > >
> > > A couple of questions and comments:
> > >
> > > * The ValidatingActionForm interface will extend the 
> ActionForm interface, right?
> > >   It only needs to add the validate() method.
> >
> > Yes.
> >
> > > * I'm not sure that we really need 
> ValidatingActionFormBase -- it's
> > > only one method in the standard interface.
> >
> > Your probably right, especially since validate() now is so simple.
> > I'll take it out.
> >
> 
> In the example application, there is one scenario where the 
> validate() method could
> really use a little more context information -- when you 
> register yourself, and the
> system wants to check for that username already being in use. 
>  We've got two options:
> 
> * Leave the validate() method with no arguments, and check 
> for this kind of
>   thing in the action class itself.
> 
> * Pass something (but what?  the servlet context?  the 
> request?) to the
>   validate() method so that it can look up what it needs.
> 
> I'm tending to think that the first approach is the 
> reasonable one on this topic.
> 
> >
> > > * Why does ActionMapping need a new property?  Can't we 
> just re-use the
> > >   formClass property?  A particular form class can be 
> validating or not, and the
> > >   controller servlet will figure that out at runtime with 
> an "instanceof" check.
> >
> > The formClass property is a class name while the inputForm 
> property is
> > a URI that points back to the calling form so we can forward back to
> > the original form if validation failed.  Just like the failure
> > property in example's ApplicationMapping.
> >
> 
> Gotcha.  That makes sense.
> 
> >
> > -jh
> >
> 
> Craig
> 

Re: ValidatingActionForm

[jh...@inst.strykercorp.com]

On Fri, 16 Jun 2000, Nestel, Frank wrote:

[snip]
> Not sure if I missed s.th. with the ValidatingActionForm.
> Looks to me, that a parameterless validate() might be not
> enough. In the concrete example of a registration like in 
> the example, I endet up with a validate() which hat to 
> differentiate between a first time log in (where entering
> a username was OK) and a later edit of user data (where
> the username was taboo, since it was kind of a database id).
> Also the bean might not know that it is part of a special 
> database, but it might need to, to verify that a new username
> does not allready exist in that database.
> 
> It's clear that all processing (new/edit and database check
> back) could be done within the bean, its more a design thing:
> 
> * Should we end up with a bean which covers all those cases.
> * Should one use a whole family of beans which have the same
>   setters and getters, but different validate()s.
> * Should a ValidatingActionForm care about the special cases,
>   leaving only basic validation to the bean?

Right now the design reflects the fact that there are two types of
validation that can be done:

1. A simple check for data format - things like required, numeric, phone
number, email address, etc...  Any kind of validation that be
expressed in code alone, without access to some external resource.  This
type of check is done in the FormBean validate() method.

2. Business Rules checks - things like the username examples from above,
does a part number exist in a part master database, etc...  Checking
business rules usually involve interacting with external resources or
model objects.  This type of check is done in an action.

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments, Kalamazoo, MI