On 6/7/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
You ask a question that is frequently debated around here :)  I can say
with quite a bit of confidence that Michael Jouravlev will be around
shortly to say DispatchActions are the ONLY way to go :)

Not the only way, just the one preferred by me :)

1) First off, it is possible to have several mappings and one action
class, using MappingDispatchAction. Speaking of Frank and me, there
are no real benefits in this approach:

* Frank does not like having one large action class
* I don't like having several mappings

2) My approach is having one mapping and one action class. This is not
just  "more simple actions" vs "more methods in one action" debate.

* With one mapping you have one URL, that may be important for some,
especially if you redirect an action to itself.
* With one action class and one form bean and possibly with one nested
business object you have clear relationship between a business object,
a web resource and a web-related code, sort of code-behind class in
.Net-speak. If your form bean is session-scoped, then it is very easy
to keep the conversation, and to send different events to the same web
resource, updating its state.
* Conceptually, a dispatch action represents a whole web resource,
while its methods represent possible actions on the web resource, a
clean paradigm.
* Less mappings in xml file, less clutter.

I prefer to have one action class and one mapping for all submit
events as well as for rendering, but many find it too complex.

It may be simpler to use dispatch action to submit events, and to use
another regular action to render a view. Thus, a web resource would be
served with two actions.

Chamal, if you decide to use a dispatch action, I suggest
EventDispatchAction, or ActionEventDispatcher if your action class
must inherit from your custom class. See these links:

http://wiki.apache.org/struts/EventActionDispatcher
http://wiki.apache.org/struts/DataEntryForm

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to