This has been a fascinating thread to catch up on! ;-) I'm more than a little surprised, though, that everyone's still "in the box" on a solution to Erik's problem.
I have exactly the same scenario that Erik does - basically, you have some code that deals with the incoming request, and some code that deals with preparing to present the next page, and you want to decouple those. One solution, which is where this thread started, is action chaining, but we know there are issues with that. A much cleaner solution involves just a little thinking outside the box. Who said that the request handling and the presentation handling code had to be in Action classes? Nobody. So don't do that. ;-) The solution I am currently using is based on the idea of "request handlers" and "display handlers". These handlers are *not* Action classes - they are entirely independent of Actions. A single HandlerAction class knows how to invoke a configured request handler first, and then invoke the appropriate display handler after that. Everything is configured externally, in XML. Using Erik's example, this lets me put the code for the delete step and the generate list view step in different classes, and externally configure the connection between the two, without using action chaining and without using action forwards. In my application, this is a strict requirement, because other people (not necessarily employed by my company) must be able to reconfigure the application itself without modifying Java code, and it's not OK to require them to understand the ins and outs of action chaining. Once any remaining wrinkles are ironed out, I hope to be able to persuade my employer that contributing this code to Struts is the right thing to do, and therefore make this extension available in contrib (or perhaps even core, given how many people seem to run into these issues). -- Martin Cooper On Thu, 12 Dec 2002, Erik Hatcher wrote: > Ted Husted wrote: > >>>Struts is not very powerful. There's no action chaining; all of > >> > > the models are one layer deep. Talking with a Struts user, I was > > reminded of the ability of an action to forward to another action, > > and it's easier than I thought. Silly rabbit. :) > > > > 'nuff said. > > > > Although, I'm among those who recommend against action-chaining, > > since it implies that there is too much business logic in the > > Action class. (The "chaining" should happen on the business tier.) > > But, there's nothing to prevent it (if you are wearing your > > bullet-proof shoes). > > I'm one of those that find action-chaining very helpful. Here's an > example of how/why I use it (all JSP's are under WEB-INF) > > - A list view of all items > - A delete link by each of the items > - User clicks to delete an item > - DeleteAction deletes the item and wants to forward back to > the list view > - An action is needed to generate the list view dynamically > > I simply chain the "success" forward of the "/delete" mapping to "/view.do". > > I've yet to see a solution that doesn't blur the delete step with the > generate list view step - and this forces actions to be tied to how its > used in the GUI, which to me goes against what Struts is all about. > Creating tiny actions that only do one single thing and then glue them > together in struts-config is something I find very helpful. > > Is there a cleaner way to do this without action chaining? > > Erik > > > -- > 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]>
