[
https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40237
]
Michael Jouravlev commented on STR-2940:
----------------------------------------
DispatchAction was introduced as Struts extension, its functionality was never
considered part of core Struts features. I believe that if dispatching were
part of Action then more people would have used event dispatching. I suppose
that DispatchAction and its flavors had enough time marinating as extensions to
grow in popularity so they could finally be added to the core.
I believe that event dispatching is an important feature. It is implemented in
many other web frameworks like ASP.NET, Stripes or even S2. I believe that
being implemented in core Action class gives this feature more weight and
attention from Struts users.
Another reason is being able to inherit from some base action while having
dispatching capabilities. This has been resolved with ActionDispatcher, but
this requires additional code exposing the plumbing and looks like a band-aid
to me. Having this functionality in Action removes the need in
ActionDispatcher. As to "more to comprehend": compare the need to understand
what ActionDispatcher is and how its execute method calls handlers on a custom
action with simply defining handlers in an action. This change makes things
simpler.
Also, I am going to add several new attributes/elements to <action> element,
and I think it would be nice to ensure that these attributes/elements are
processed uniformly by any action, not just by specific descendants of
DispatchAction and such. To my mind this makes mapping/action relationship more
tight and predictable.
Frank you are right, I do want to promote event-based mindset and to update S1
documentation reflecting this approach. This has nothing to do with maintaining
of existing applications because full backward compatibility will be preserved.
I can reply with the same message to you, Paul. If you have working
DispatchActions why would you want to change them? This change is for new
development.
As to S1 becoming a legacy, again, this change preserves full backward
compatibility, and those who switch to S2 should not care at all should they? I
am personally going to start a new project with S1, so Paul, I do not see S1
being frozen in maintenance mode, I want to improve it as a separate product
not as an outdated version 1. Remember that when S1/S2 names were chosen it was
agreed upon that these are names not versions and that S2 does not necessarily
includes all S1 features and that S1 development does not have to stop with
release of S2.
For new developers, S1 will provide native event dispatching in one Action
class, so they should not learn about EventDispatcher, DispatchAction,
EventDispatchAction, "parameter" attribute, etc. They will be able to simply
define events in the mapping and then define handlers in the Action, that is it.
> 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.
