struts 2 actions coupled to pages?

Question

Problem

While developing struts2 application I was asked to implement two pages: the one listing current user's books and the other listing current user's CDs. So I decided to implement two struts2 actions: ListBooks and ListCDs, both of them having standard dispatch result type, pointing to corresponding JSP pages.

Later the client changed his mind and decided that both lists of books and CDs should reside on the same page. So how can I reuse my actions so that I wouldn't need to rewrite any classes.

My attempt

First approach was to use action chaining. So that both actions can contribute their properties to value stack. But then there is a problem: we establish some unnatural order for actions. If I chain ListBooks to ListCDs then invoking ListCDs on its own causes some erroneous behavior - as it will result in a page where both books and CDs should be listed.

Another way was to use action tags. But I don't like it either as it forces separation of my page into multiple JSP parts and generally feels like doing things not in struts2 style.

Questions

So how do I combine my actions to form single page in a "clean way"? The problem seems to be so simple.

Another question spawned by this problem is about struts2 design - do struts2 actions take too much responsibility? Apart from being "single units of work" they are also coupled to presentation level. Everytime I change the structure of my pages I have to think about redesigning my actions. Am I missing something or struts2 really has this type of design weakness?

Answer 1

Struts 2 actions only take too much responsibility if they're designed that way--they should act as a thin bridge between the web and business layers.

Each of the earlier actions should have just had a service to retrieve the items in question. The new action would have both services, and expose the results of the user's books and CDs to the view layer.

Of course they're coupled to the presentation level--they are what determines what's available to the view. In any action-based framework this is the case, whether it's the action itself, the model in a ModelDriven action, a Spring MVC controller returning a view, a Struts 1 action form, request attributes, etc.

The amount of work necessary to support the type of change you describe is almost nothing: move the service from one action to another, and either expose the additional results directly, or add them to the exposed model.