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]