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...
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.
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
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 ]