In your case, something to consider might be to use BSF scripts instead of Java Actions.
<http://struts.sourceforge.net/struts-bsf/index.html> Another idea would be to reduce the business classes to Commands (using the Command Chain of Command package) <http://jakarta.apache.org/commons/sandbox/chain/>. A standard Action could then be used to run one or more business Commands. Something else that has been mentioned is the idea of using JSPs for Actions, but I don't know that anyone has implemented anything yet. -Ted. On Thu, 01 Jan 2004 10:49:46 -0500, Tim Lucia wrote: > 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: struts-user- >> [EMAIL PROTECTED] For additional commands, e-mail: >> [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: struts-user- > [EMAIL PROTECTED] For additional commands, e-mail: > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
