This week's book giveaway is in the Big Data forum.
We're giving away four copies of Elasticsearch in Action and have Radu Gheorghe & Matthew Lee Hinman on-line!
See this thread for details.
The moose likes Struts and the fly likes Pattern = 20 nearly identical DispatchActions - now what? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Elasticsearch in Action this week in the Big Data forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Pattern = 20 nearly identical DispatchActions - now what?" Watch "Pattern = 20 nearly identical DispatchActions - now what?" New topic

Pattern = 20 nearly identical DispatchActions - now what?

Rusty Enisin
Ranch Hand

Joined: May 26, 2005
Posts: 107
I am building an application that has about 20 pages that all need to be able to display, add, edit and delete data on the page. In order to save myself from having to write 80 actions ( ) I decided to use a DispatchAction. This chopes the number of actions to 20. As much as this is a great improvement, I wonder if I can do more.

I have 20, nearly identical, DispatchActions. The only real differences between the actions will be the action form and the objects that get added, created, deleted and updated.

Maybe these differences are enough to justify 20 different actions. I have a couple of different ideas that might be able to reduce the number of actions. But maybe I am barking up the wrong tree.

1. Use one DispatchAction that then calls different business classes based on the request. Maybe the business classes could be retreived from a factory. This reduces the number of actions, but not the number of classes. Also, the complexity of the factory may be more than it is worth. I don't know.

2. Have 4 action classes. One each for display, update, add and delete. Each one knows how to do its thing. The only ones of real complexity are update and add because they need to validate the form.

When I stand back and look at these two ideas, they are starting to look the same (4 actions = 4 dispatch methods). :roll:

Is there a better way to do this?

[ June 14, 2005: Message edited by: Rusty Enisin ]
[ June 14, 2005: Message edited by: Rusty Enisin ]

The squeaky wheel gets the grease. Well, that or replaced...
Merrill Higginson
Ranch Hand

Joined: Feb 15, 2005
Posts: 4864
You might consider creating an abstract base Action class that defines the four dispatch methods with most of the logic in them. The class could contain some abstract methods to be implemented by the subclasses to do things that are specific to each form. You'd then write 20 subclasses of this Action class. You'd still have 20 classes, but most of the logic would be in the superclass, and each class would have only the logic that is unique to that class.

Consultant, Sima Solutions
Rusty Enisin
Ranch Hand

Joined: May 26, 2005
Posts: 107

I have looked into this more. Even if I consolidated the classes, I will still have different ActionForms for each action. So I will have to put a different entry in struts-config.xml for each. I would have to do that anyway.

The problem with consolidating the actions is that each one will need a different form bean. There are two ways around that; use one conglomorite form bean (this is dumb) or have different mappings in struts-config.xml for each form bean mapped to a new action name all using the same action class for the type. The last option is not so bad, because you would have to have done that anyway.

Merrill seemed to hit it on the nose. About the best I can do is extend some parent class that contains methods common to all decendants. In the end I still end up with a bunch of classes. But it cannot be helped.

1 parent DispatchAction + 20 decentant DispatchActions + 20 form beans + 20 create JSP forms + 1 generic delete JSP + 20 update JSP forms + 1 generic display jsp (maybe have to do 20) = 83+ objects to code plus configuration for all. And it looked like a small app. :roll: And this is just the web end of the app

Time to get started.
Jack Wiesenthaler
Ranch Hand

Joined: Jul 26, 2001
Posts: 75
Merill is right, you need to provide the common functionality between all 20 actions in a base DispatchAction class and then extend that to provide more specific functionality.
Junilu Lacar

Joined: Feb 26, 2001
Posts: 5504

I have been looking at the Spring Framework lately and the approach using fewer DispatchActions + Factory might be more manageable if you use a Spring BeanFactory or ApplicationContext. The examples I've seen that use Spring seem to be very well layered (look at Matt Raible's Equinox and Appfuse) and well factored with minimal code duplication, if any at all. Couple Spring with a persistence framework like Hibernate (as one of the Equinox examples does) and you're down to writing just the bare essential code; all the nitty-gritty stuff is taken care of by the frameworks. It's pretty sweet. I encourage you to check it out.

BTW, there is an Equinox-Struts example out there that uses DynaValidatorForms and that also helps to reduce the number of classes you have to write.
[ June 14, 2005: Message edited by: Junilu Lacar ]

Junilu - [How to Ask Questions] [How to Answer Questions]
Rusty Enisin
Ranch Hand

Joined: May 26, 2005
Posts: 107
Thanks all. I will look into it.
I agree. Here's the link:
subject: Pattern = 20 nearly identical DispatchActions - now what?