On Wed, 31 Dec 2003 12:36:33 -0500, Tim Lucia wrote: > So is it a bad design if you have > > > Action1 -> add CollectionOfObject1 to request > Action2 -> add Object2 request > > > And then chain them together to produce two request attributes? I > have some pages which display a list of Object1, and other pages > which require the Collection to populate a select. So I define > action path 1 to be action 1 and forward to the display for the > Collection of Object1, and define action path 2 to be action 1 > forward to action 2 forward to editor page which has a select of > collection of object 1, while editing Object2.
One common strategy is to use one action as a "page controller" and another as the "business transaction controller". The "business" action works as a go between with the business API and DAO objects. The Action class extracts any needed input from the ActionForm and packages for the API/DAO objects. If appropriate, it also bundles any output and places it in a servlet context, sometimes by populating an ActionForm, other times by creating some other bean. The "page" action ensures that whatever assets the page needs are available. These may be lists for drop-down boxes and so forth. This may also mean interacting with the API/DAO objects, but the interaction is static and driven by the page display requirements, rather than what the user input.. As mentioned, each of these actions should represent a single "unit of work". The business Action is an adapter for the user input. The page Action is an adapter for the page output. The core idea is that Actions are Adapters -- not the actual working classes. When people start chaining several actions together, it is usually a signal that the Actions classes are doing actual work, rather than just acting as a go-between with the business classes. The problem with Actions doing the work is that these classes are bound to Struts and to the HttpServlet platform. Struts Actions are not easy to reuse outside of Struts and are more difficult to test than POJO business classes. Creating your own set of business API or DAO classes isn't difficult. You can use a PlugIn to create a instance of your classes in application scope under a known name and then have the Actions call them there. Just be sure they are thread-safe, like Actions. Or, depending on your circumstances, Actions can create new instances of business classes so you don't have to worry about thread-safety. Object creates are a lot cheaper than they used to be. If several of the page or business Action classes need to do the same thing that isn't business-related (create some presentation collection or what-not), you can put that code in a base Action that any subclass can call. In that way, you get code-reuse the old-fashioned way, instead of by making multiple trips through the HTTP layer. HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
