Hi Mark,
like Adam said, i also have one "super-action-class" :-)
i declare it as abstract an implement execute()-methode
form Action
inside execute(), i call an abstract methode (e.g. doExecute())
so our ActionServlet(it�s RequestProcessor...) calls execute()
and every subclassed doExecute().
there is a "sample-code" below:
instead of ActionForm-Klasses i also use DynaActionForms.
but i use DynaValidatorForm for using Validator-Framework.
<form-bean name="logonForm"
type="org.apache.struts.validator.DynaValidatorForm">
<form-property name="user" type="java.lang.String" />
<form-property name="password" type="java.lang.String" />
</form-bean>
i use PropertyUtils.copyProperties()
(from the nice jakarta-commons-beanutils-project)
inside an action.class to get the form-properties:
PropertyUtils.copyProperties(myDataTransferObject,form);
it copied all properities from form to your business-objects
if the props are named equal!!
for "manually" access
you have to use
Integer integer = (Integer)form.get("ageOfMisterX");
form.set("ageOfMisterX",new Integer("33"));
because all properties are savaed in a HashMap
hope that helps.
cheers
Matthias
----------------------------------------------------
public abstract class SuperAction extends Action{
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
//do common things
return doExecute(mapping,form,request,response);
}
public abstract ActionForward doExecute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;
}
-----Original Message-----
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 22, 2004 12:15 PM
To: Struts Users Mailing List
Subject: Re: [Newbie] Is it worth subclassing your own Action and
ActionForm classes to attain code re-use?
On 02/22/2004 05:40 AM Mark Jones wrote:
> My application allows a user to make various different types of
> bookings for a (fictional!!!) hospital and logs them in a database.
> Each type of booking has a set of common properties but also different
> ones depending on the type of booking being made.
>
> I have divided my classes into a BookingAction and BookingActionForm
> superclass and subclasses (such as AmbulanceBookingAction and
> AmbulanceBookingActionForm) because I anticipate creating other
> subtypes of BookingAction that use the same properties in the
> BookingAction class but not in the AmbulanceBookingAction subclass.
> This initially seemed to me to be in keeping with programming for code
> re-use and extensibility.
I have just one Action class for the whole app that all my Action
subclasses inherit. It does all the common processing that I need. It is
now after 2 years on the project fairly complex but it is really all
common functionality.
I can't see any need in my situation for having a different Action
superclass for each module.
>
> My problem with this is, if a user submits a form which posts its data
> via the ActionServlet to the AmbulanceBookingAction subclass, how
> would I ensure the BookingAction class did its stuff? Would it be
> better / easier to use separate, non-derived (from my superclasses)
> Actions and ActionForms to handle each type of booking and not
> subclass BookingAction and BookingActionForm (even though I would be
> repeating the some of the same properties common to each different
> type of booking)?
>
You make sure they do their stuff because they have the perform() or
execute() method, and they call the actual AmbulanceBookingAction for
example.
> I am concerned, though, not to lose points for not reusing code. It
> just seems to me, though, that trying to divvy the handling of the
> form data via inheritance is too complicated and / or unnecessary.
>
I once had a ActionForm superclass with getter / setter methods for
frequently occuring fields - but dropped it because the advantage was
trivial. And I started using DynaActionForms.
Adam
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
