[
https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40319
]
Hubert Rabago commented on STR-2940:
------------------------------------
IIRC, Michael first proposed this when EventDispatchAction was first
introduced, and I was against the idea then. Now that I've used it in an
actual application, I'm beginning to change my mind. Forms that can do more
than one type of action, and I'm not just talking buttons, can be common, and
EventDispatchAction made it a pleasure to support them. I think this is one of
those things were you might understand what it does and how it works, but until
you actually use it, you can't really appreciate the difference it makes (like,
uhm, Spring).
I understand the argument against giving the base Action the full functionality
of EventDispatchAction, but what about a compromise? What about adding support
for EventDispatchAction configuration in struts-config.xml with the suggested
<event> elements? The elements would only apply if the user's action uses
Event-type dispatching. This would be like the <form-property> element which
wouldn't apply if the form bean wasn't a DynaActionForm.
> Base Action should implement dispatch functionality (building a
> coarse-grained action)
> --------------------------------------------------------------------------------------
>
> Key: STR-2940
> URL: https://issues.apache.org/struts/browse/STR-2940
> Project: Struts 1
> Issue Type: Improvement
> Components: Core
> Reporter: Michael Jouravlev
> Assigned To: Michael Jouravlev
> Priority: Minor
>
> Since DispatchAction was introduced, it became possible to write actions in
> two styles:
> * Fine-grained actions that process only one kind of request / command /
> event. These are standard Action classes where code is written in execute()
> method.
> * Coarse-grained actions that process several commands/events. These are
> DispatchAction, MappingDispatchAction, LookupDispatchAction and
> EventDispatchAction.
> Building coarse-grained actions always has been kind of hack with either
> using the generic "parameter" attribute of an action mapping, or with
> building event-to-method maps in the code.
> The proposed enhancement has the following goals:
> * Add dispatch functionality to base Action without affecting current Action
> usage.
> * Accept that both fine-grained and coarse-grained approaches are valid and
> should be equally represented; one approach should not suffer from dominating
> of another.
> * Extend syntax of an action mapping to allow event defintion using
> designated elements instead of using hacks like generic "parameter" attribute.
> * Allow using wildcards in event definitions.
> * With a coarse-grained action it is easier to introduce a concept of a web
> resource that can be affected by several events, can have state and can
> render several views. This concept allows to draw some similarities between a
> Model 2 framework like Struts and code-behind framework like .NET: Action +
> ActionForm is a code-behind, JSP is markup, event-handling methods in an
> Action class are event handlers.
> Introduction of Command class in Struts 1.3.x does not affect coarse-grained
> actions, these actions should be implemented with an Action class.
> Action class retrofitted to support dispatch functionality will behave
> exactly like EventDispatchAction when used as a coarce-grained action.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
