Ted, Thanks for the reply.
Putting methods in the base action(s) works (since the actions are related by what attributes they add to the request or session.) The down side is that the page designer who is ignorant of Java (or may not have access to the code) can't make changes this way. If I have an action to retrieve each business object and put it in the request (session) under a known key, then the page designer can chain these together to produce the objects necessary for the view. I hesitate to say that the actions are "doing actual work", other then the bare minimum - access the DAO to get a (list of) object(s) and place it (them) in a request (session) attribute. (Background note -- I have a requirement where there will be customizations done by field engineers at various customer sites. They need to know how to move tiles around (new layouts), and understand basic struts tag libraries, and HTML [which they already know]. By chaining actions, they can use the existing .class files without us shipping the java sources and having them modified in the field.) Happy New Year, Tim > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 31, 2003 4:10 PM > To: Struts Users Mailing List > Subject: RE: Problem with action chaining > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
