So if I had an XXXXAction that handled the following operations on an account:
-createAccount -retrieveAccount -updateAccount -deleteAccount instead of having these 4 methods defined, in a single action class, you would define a business bean in the action mapping and something similar to the following operations would take place in sequence when the XXXXAction was invoked. -The XXXXAction class accesses business bean (creates or retrieves). -The XXXXAction class converts (directly or indirectly) user input into expected business input arguments . -The XXXXAction class invokes business bean hotspot method with business arguments. -The business bean processes input and performs the appropriate command logic. -The business bean returns a business bean return object. -The XXXXAction class processes the business bean return object to determine the ActionForward. -The XXXXAction class returns ActionForward to the web controller. So you might end up having business beans/delegates like CreateAccountCommand, RetrieveAccountCommand, UpdateAccountCommand, and DeleteAccountCommand, instead of separate XXXXAction classes or a single XXXXAction class with the four methods. Each of the four business beans might then delegate to a common business service called something like IAccountService to handle or delegate processing. Did I interpret that correctly? robert > -----Original Message----- > From: Molitor, Stephen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 2:46 PM > To: 'Struts Users Mailing List' > Subject: RE: [Struts Tips] #2 - Template Method Dispatch Action? > > > Yes, you're absolutely right. The business bean approach is less > connected > to the web tier, for better or worse, and does not have to be a Singleton > (didn't think of that one). The framework approach is closer to the web > tier. The two approaches are similar in some respects, but different in > others, and have different consequences in terms of convenience and reuse. > I guess what I really meant is that they are not mutually > exclusive. If the > common logic can be cleanly separated from the web tier, then the business > bean approach makes more sense, as it's more reusable. If the > logic is tied > to the web tier, then framework approach makes more sense as it's more > convenient to access the web tier. One could use both approaches in the > same app, on a case by case basis. > > One question: Do your business beans typically implement the > business logic > directly, or do they forward to another existing businesses tier (EJB's, > whatever)? If they forward, then they're kind of like business delegates. > This is the situation I was thinking of when I said the framework and > business bean approaches seemed similar. The business delegate > layer might > be somewhat reusable outside a web app, but the real reusable > logic would be > in the true business backend that the business delegate forwards to. In > this case, it might partially be a style issue which to use. Putting the > mapping and delegating to the business backend logic in separate business > delegate ('business bean') classes would be a bit more reusable, and more > configurable, but would add another layer. Putting this logic in > framework > actions might be a tad more convenient, but slightly less reusable. > > This business bean approach sounds really interesting. It sounds like a > business bean is a business tier version of an Action. It has a known > input type, similar to ActionForm, a known return type, similar to > ActionForward, and a known signature, similar to Action.perform. > One could > introduce a business tier version of the ActionServlet controller, that > could call business logic validation methods on the input object, manage > transactions, etc. In other words, apply the command and controller > patterns to the business tier. Cool! > > Steve Molitor > [EMAIL PROTECTED] > > > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 9:50 AM > To: Struts Users Mailing List > Subject: Re: [Struts Tips] #2 - Template Method Dispatch Action? > > > "Molitor, Stephen" wrote: > > The business bean and framework + > > approaches actually seem pretty similar to me. The only difference is > > whether the main extension point is a separate class, or a method of the > > action class. In either case the extension point is specified in the > > configuration file. > > > I would say that the consequences of the business bean approach include > > + the beans can be reused outside of a web application > + a bean can be instantiated for every request or could be designed as a > singleton > + access to web-tier resources is indirect at best > + business-beans can nest other business beans > > > Consequences of the framework approach include > > + the framework Action is bound to Struts > + the framework Action is always a singleton, instantiated once for the > life of the application, and must be thread-safe > + the framework Action has direct access to web-tier resources > + forwarding or including other Actions involves outside agents, like > Struts and the container, which may introduce their own behaviours > > Others? > > "Molitor, Stephen" wrote: > > > > Why are the Framework and Dispatch approaches mutually exclusive? It > seems > > like you could do both -- have a base action with extension points (hot > > spots), and the main hotspot method (i.e. 'executeLogic') could > optionally > > be a dispatch method. This would help with create/update/delete > operations, > > where all the logic is the same except for which db operation > to perform. > > Of course it's not the only way to do it -- the 'business bean' approach > you > > mention, where the mapping specifies the business class, would also work > > nicely. But the framework + dispatch approach could cut down on the > number > > of classes (business bean or action). The business bean and framework + > > approaches actually seem pretty similar to me. The only difference is > > whether the main extension point is a separate class, or a method of the > > action class. In either case the extension point is specified in the > > configuration file. > > > > Steve Molitor > > > > > I believe the Dispatch and Template (or Framework) class > approaches may > > > be mutally exclusive. The idea of the Dispatch class is that you can > > > vector to an arbitrary method. The idea of a Framework class, like > > > SuperAction uses, is that a known entry method calls a number of > > > hotspots (or extension points) that you can override. > > > > -----Original Message----- > > From: Ted Husted [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, June 01, 2002 7:31 AM > > To: Struts Users Mailing List > > Subject: Re: [Struts Tips] #2 - Template Method Dispatch Action? > > > > "Molitor, Stephen" wrote: > > > As is, the DispatchAction in Struts 1.02 cool, but does not provide > > direct > > > support for eliminating or consolidating duplicate code from related > > tasks. > > > It's just a different style. With DispatchAction, one can > have one big > > > action class to handle related tasks, as opposed to several little > Action > > > classes. However, related tasks often have some common logic > that needs > > to > > > be performed for all the tasks, and other logic that is > specific to each > > > task. It would be cool if there was a DispatchAction that provided > hooks > > > for the common logic. > > > > For something similar, see the SuperAction in the Scaffold package. > > > > > http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/ > framework/ > > main/org/apache/scaffold/http/SuperAction.java > > > > I believe the Dispatch and Template (or Framework) class approaches may > > be mutally exclusive. The idea of the Dispatch class is that you can > > vector to an arbitrary method. The idea of a Framework class, like > > SuperAction uses, is that a known entry method calls a number of > > hotspots (or extension points) that you can override. > > > > You could share common utility methods among various Dispatch methods by > > passing all needed parameters through the signature, but how to merge > > this idea with a framework class approach isn't jumping out at me. > > > > The closest thing may to be use a relay action to forward the request to > > another Action based on a framework class. You then just override a > > business extension method on the framework Action (like > > SuperAction.ExecuteLogic). This doesn't reduce the number of Actions, > > but it does let you share as much code as possible > > > > Personally, I use very few Struts Actions in an application. Instead I > > tend to specify a business class as part of the action mapping, and then > > have the Action call that, using a base Action like the above. The > > business beans have a hotspot method with a known signature. The Action > > just instantiates the business bean (like the ActionServlet instantiates > > a form bean), calls the signature, and copes with the result. (Just like > > the ActionServlet calls an Action.) > > > > This trades Actions for business beans, but minimizes coupling to Struts > > and maximizes code reuse between platforms. > > > > The Advanced Struts skeleton for Adalon, uses the same approach. (No > > surprise, I wrote it =:) > > > > http://synthis.com/products/architectures/struts/ > > > > Synthis has released the skeleton code under the Apache License, and I'm > > integrating it back into the Scaffold package and updating the Artimus > > application to use the new clases. So, there will major updates to these > > next week. All the same ideas, but with some improvements to the > > implementation. Film at 11. > > > > -- Ted Husted, Husted dot Com, Fairport NY US > > -- Developing Java Web Applications with Struts > > -- Tel: +1 585 737-3463 > > -- Web: http://husted.com/about/services > > > > "Molitor, Stephen" wrote: > > > > > > As is, the DispatchAction in Struts 1.02 cool, but does not provide > > direct > > > support for eliminating or consolidating duplicate code from related > > tasks. > > > It's just a different style. With DispatchAction, one can > have one big > > > action class to handle related tasks, as opposed to several little > Action > > > classes. However, related tasks often have some common logic > that needs > > to > > > be performed for all the tasks, and other logic that is > specific to each > > > task. It would be cool if there was a DispatchAction that provided > hooks > > > for the common logic. One approach would be to use the > Template Method > > > pattern, perhaps something like this: > > > > > > public class TemplateMethodDispatchAction extends DispatchAction { > > > > > > public ActionForward perform(ActionMapping mapping, > > > ActionForm form, > > > HttpServletRequest request, > > > HttpServletResponse response) { > > > beforeHook(); > > > ActionForward forward = super.process(mapping, form, request, > > response); > > > return afterHook(forward, mapping, form, request, response); > > > } > > > > > > protected void beforeHook(ActionMapping mapping, > > > ActionForm form, > > > HttpServletRequest request, > > > HttpServletResponse response) { > > > // does nothing by default > > > } > > > > > > protected ActionForward afterHook(ActionForward forward, > > > ActionMapping mapping, > > > ActionForm form, > > > HttpServletRequest request, > > > HttpServletResponse response) { > > > return forward; // just returns the forward that was passed in by > > > default > > > } > > > > > > } > > > > > > Defing the beforeHook and afterHook methods in derived clases would be > > > optional. If you don't define them, TemplateMethodDispatchAction > behaves > > > just like DispatchAction. If you choose to define them, you > have slots > to > > > put common pre/post processing logic. > > > > > > The afterHook method returns an ActionForward to allow for cases where > the > > > logic to determine the next page is common for all tasks, and can thus > be > > > coded in one place in the afterHook. However, the default > implementation > > of > > > afterHook just returns the forward returned by the task > specific methods > > > (i.e. create, update, delete), to allow for cases where the logic to > > > determine the next page varies with the task. > > > > > > Of course, you can use procedural decomposition to factor out > the common > > > logic instead, and rely on the task specific methods (i.e. create, > update, > > > delete) to remember to call the appropriate pre/post > processing methods > at > > > the right time. However, the calls to the common methods would still > get > > > duplicated in each task specific method. The Template Method approach > is > > > more automated. > > > > > > Does Struts 1.1 have anything like this? > > > > > > Steve Molitor > > > [EMAIL PROTECTED] > > > > > > -----Original Message----- > > > From: Ted Husted [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, May 31, 2002 6:12 AM > > > To: [EMAIL PROTECTED] > > > Subject: [Struts Tips] #2 - Use DispatchAction to organize related > > > operations > > > > > > Any software application is defined by the things it can do > for you. In > > > a Struts Web application, the things an application does is usually > > > defined by its action-mapping elements. An action-mapping is > designed to > > > be the target of an HTML form, and is often used with hyperlinks as > > > well. > > > > > > Each action-mapping can specify a Struts Action class as its > handler. In > > > larger applications, developers can find themselves managing dozens or > > > even hundreds of Action classes. > > > > > > In practice, many of these Action classes handle related operations, > > > often evidenced by their name. A package might include separate > > > RegCreate, RegSave, and RegDelete Actions, which just perform > different > > > operations on the same RegBean object. Since all of these > operations are > > > usually handled by the same JSP page, it would be handy to also have > > > them handled by the same Struts Action. > > > > > > A very simple way to do this is to have the submit button > modify a field > > > in the form which indicates which operation to perform. > > > > > > <SCRIPT> > > > function set(target) { > > > document.forms[0].dispatch.value=target; > > > } > > > </SCRIPT> > > > > > > <html:hidden property="dispatch" value="error"/> > > > <html:submit onclick="set('save');">SAVE</html:submit> > > > <html:submit onclick="set('create');">SAVE AS NEW</html:submitl> > > > <html:submit onclick="set('delete);">DELETE</html:submit> > > > > > > Then, in the Action you can setup different methods to handle the > > > different operations, and branch to one or the other > depending on which > > > value is passed in the dispatch field. > > > > > > String dispatch = myForm.getDispatch(); > > > > > > if ("create".equals(dispatch)) { ... > > > > > > if ("save".equals(dispatch)) { ... > > > > > > The Struts Dispatch Action is designed to do exactly the same > thing, but > > > without messy branching logic. The base perform method will check a > > > dispatch field for you, and invoke the indicated method. The > only catch > > > is that the dispatch methods must use the same signature as perform. > > > This is a very modest requirement, since in practice you > usually end up > > > doing that anyway. > > > > > > To convert an Action that was switching on a dispatch field to a > > > DispatchAction, you simply need to create methods like this > > > > > > public ActionForward create(ActionMapping mapping, > > > ActionForm form, > > > HttpServletRequest request, > > > HttpServletResponse response) > > > throws IOException, ServletException { ... > > > > > > public ActionForward save(ActionMapping mapping, > > > ActionForm form, > > > HttpServletRequest request, > > > HttpServletResponse response) > > > throws IOException, ServletException { ... > > > > > > Cool. But do you have to use a property named dispatch? No, you don't. > > > The other step is to specify the name of of the "dispatch" property as > > > the "parameter" property of the action-mapping. So a mapping for our > > > example might look like this: > > > > > > <action > > > path="/reg/dispatch" > > > type="app.reg.RegDispatch" > > > name="regForm" > > > scope="request" > > > validate="true" > > > parameter="dispatch"/> // Which parameter to use > > > > > > If you wanted to use the property "o" instead, as in > o=create, you would > > > change the mapping to > > > > > > <action > > > path="/reg/dispatch" > > > type="app.reg.RegDispatch" > > > name="regForm" > > > scope="request" > > > validate="true" > > > parameter="o"/> // Look for o=dispatchMethod > > > > > > Again, very cool. But why use a JavaScript button in the first place? > > > Why not use several buttons named "dispatch" and use the values to > > > specify the operation. > > > > > > You can, but the value of the button is also its label. This means if > > > the page designers want to label the button something different, they > > > have to coordinate with the Action programmer. Worse, localization > > > becomes virtualy impossible. > > > > > > If you prefer not to use JavaScript buttons, you can use the > > > DispatchLookup Action instead. This works much like the > DispatchAction, > > > but requires more setup. We'll explore the DispatchLookup > Action in Tip > > > #3. > > > > > > HTH, Ted. > > > > > > --- > > > > > > Struts Tips premiere twice weekly on the MVC-Programmers List. To > > > subscribe, visit BaseBean Engineering < http://www.basebeans.com >. > > > > > > An archive of past tips, like this one, is available at < > > > http://jguru.com/faq/subtopic.jsp?topicID=893704 >. > > > > > > About Ted. Ted Husted is an active Struts Committer. He also moderates > > > the Struts mailing list and the JGuru Struts > > > FAQ. > > > > > > Copyright Ted Husted 2002. All rights reserved. > > > > > > _______________________________________________ > > > MVC-Programmers mailing list > > > [EMAIL PROTECTED] > > > http://www.basebeans.com:8081/mailman/listinfo/mvc-programmers > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- Ted Husted, Husted dot Com, Fairport NY US > -- Developing Java Web Applications with Struts > -- Tel: +1 585 737-3463 > -- Web: http://husted.com/about/services > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
