struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <>
Subject RE: Multi-page form
Date Wed, 11 Oct 2000 17:54:25 GMT
> -----Original Message-----
> From: Craig R. McClanahan []
> Sent: October 10, 2000 9:10 PM
> To:
> Subject: Re: Multi-page form
> Mike La Budde wrote:
> > So, like its cousin before it, ActionForm will become a (base) class
> > instead of an interface.
> >
> > For what it's worth, I prefer leaving both as interfaces 
> and providing
> > ActionBase and ActionFormBase for people to inherit from 
> should they choose
> > to.
> Believe me, I wish this were a reasonable path ... but it 
> appears to me that it
> is not.
> Consider the fact that, in the future, we want to enhance our 
> notion of what an
> ActionForm does with some new optional functionality.  For a 
> concrete example,
> consider the desire to add a validate() method on a 
> ValidatingActionForm that
> takes additional arguments to provide context information.
> If ActionForm is a class, you can add a new method to 
> ActionForm and provide
> reasonable defaults, without breaking any existing ActionForm 
> beans unless they
> happen to already have a method with the same signature.
> If ActionForm is an interface, we have just broken every 
> single ActionForm bean
> ever written by anyone in the entire world -- until they 
> update every single such
> bean (and big apps are going to have *lots* of them), they 
> cannot upgrade to the
> new version of Struts that uses the new functionality.
> A very similar situation is happening with the JSP 1.2 spec 
> -- a new method
> (resetCustomAttributes) is being added to the Tag interface.  
> Most people
> (including me in Struts :-) build their tags on top of TagSupport -- a
> convenience base class equivalent in purpose to 
> ActionFormBase -- and are immune
> to this change.  But anyone who builds their beans by 
> "implements Tag" instead is
> stuck until the add the new method.
> One might argue that, well, everyone is going to just 
> "extends ActionFormBase"
> anyway.  If so, then why have both in the first place :-).

Because most of the time people are indeed going to extend the 'base'
implementation, but if they really need to or want to, they can do a bit of
extra work and implement the interface themselves (through delegation, or
however). Why should the library limit the options. It is ok as long as
people know the implications of each variant.

> > Doing it this way facilitates allowing people to plug in 
> existing code
> > a little bit easier. That is, one could simply implement 
> the interface in
> > an existing class and add the required method(s). Rather 
> than being forced
> > to create a new class and using an instance of the existing class to
> > delegate the work to...
> >
> That was the original reason that ActionForm was an interface.
> However, I discovered that it encourages people to do the 
> "wrong" thing (IMHO),
> by adding "implements ActionForm" to their data layer objects 
> or EJBs, instead of
> creating new beans.  This causes problems because the user 
> request is not
> necessarily semantically correct (that is, your data layer 
> bean might reject
> invalid property settings), and you will not be able to 
> faithfully reproduce the
> input values last entered by the user (which is the whole 
> point of an ActionForm
> bean).
> Additionally, you can have problems if the user leaves part 
> way through an update
> without completing it.  Many data layer objects are designed 
> to start locking
> things in the database when you start updating them.  Now you've got a
> half-completed update to get rid of, (usually you can do a 
> ROLLBACK but there's a
> performance cost of throwing away all that work) versus 
> simply throwing away the
> ActionForm bean for the form that the user did not finish.
>  I've come to believe that we really should want separate 
> ActionForm beans, even
> though most or all of the properties are the same.  Think of 
> ActionForm beans as
> part of the View layer of MVC (where data layer beans are 
> Model), and it will
> make more sense why they are different.

I just have a fundamental problem with the library dictating this sort of
thing, everything else being equal (i.e. there are no other serious
implications). While I agree that in many cases (e.g. an EJB data bean with
validation and maybe some real logic) an existing bean class is not
suitable, there are other perfectly valid cases in which a suitable (simple)
bean already exists.

This is quite arguable, but I also think that a monolithic base class the
keeps being extended (as opposed to using interfaces and add-ins) goes
against the current thinking on the most flexible way to build extensible
libraries. The current vs. the old AWT is just one example of this...

View raw message