This is our experience using DispatchAction. I'll try to summarize: Our application uses DispatchAction. In fact, we have one action for each use case. All administration use cases (Operators admin, accounts admin, banks admin, etc) uses actions that extends from an AdministrationBaseAction. This action implements Template pattern. It has filter, list, detail, update, save and delete methods and has protected methods to be overriden if necesary (beforeSave, afterList, etc). In the simplest case, we do'nt extend this base action. We place business logic in Services (JMX Services) implementing a UseCase Pattern or facade pattern, and these services has a common interface (AdministrationService) that has methods like list, delete, save, etc., so visibility from AdministrationBaseAction is to AdministrationService and services are got by a ServiceLocator pattern. We configure servicename for each action in a set-property in struts-config file (JNDI service name).
Saludos desde Buenos Aires. Guillermo. PD [OT] : Visit el calafate!! http://www.elcalafate.com.ar/ -----Original Message----- From: Scott McClure [mailto:[EMAIL PROTECTED] Sent: Sábado, 03 de Enero de 2004 12:50 p.m. To: [EMAIL PROTECTED] Subject: Design Questions I am trying to design a basic struts application, and I would like the opinion of those on the list about some design questions. First, I was thinking about using a single UserForm to validate all forms relating to a user, for instance. The problem is, is that some fields would not be necessary for update actions and their validation code would throw a ActionError with the default value. I could use conditional validation in the ActionForm based upon the ActionMapping, but that would create ties between the config file and code that I am not sure I want to make. What is your opinion? Next, I am trying to tackle the problem of the granularity of my Action objects. At first, I thought about using a DispatchAction, but that only allows me to use one ActionForm for all of the Actions in that class. Then, I thought that maybe wildcards would solve my problem. Wildcards, though, seem like a security concern, where it would be theoretically possible to run an action that is not intended to be run (to exploit any handling errors). Also, I am not sure if that solves any granularity problems, but merely simplifies configuration in the config file. Are there any other good solutions for solving granularity problems? Did I mis-understand DispatchAction? General comments on security with wildcards would also be very interesting. Also, slightly off-topic of my previous questions, what naming conventions do people use for application messages? In struts I have seen a general format of prompt.*, heading.*, and using page specific messages under the page name. What are some suggestions? I want to resolve to a naming standard now so I dont have to go through and change everything if it becomes a code managibilty concern. Thanks, Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
