Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <39E3BDEA.BC0E586E@eng.sun.com>
Date: Tue, 10 Oct 2000 18:10:02 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: struts-user@jakarta.apache.org
Subject: Re: Multi-page form
References: <39E2867E.D3496917@mindspring.com>
	 <39E31FE0.86212666@s1.com>
	 <39E335E3.5124F6BD@s1.com>
	 <39E33E54.EAD4E3C2@s1.com>
 <5.0.0.25.2.20001010131447.021a17e0@mail.mke.hksystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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 :-).


> 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.

>
> Mike
>

Craig

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat