[
https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40229
]
Paul Benedict commented on STR-2940:
------------------------------------
Some musings of my own which go to both points of Michael and Frank:
1) In my personal viewpoint, future S1 releases is to enhance existing Struts
applications. While it is enjoyable to believe people will start a project with
S1 today, the reality is S2 is very compelling for new applications. My focus
on S1 is, as I said, to enhance existing Struts applications; perhaps S2 is a
more appropriate place for this.
2) Because I use dispatch actions myself, I don't know how I could take
advantage of dispatching built into the Action. The reason is because I have
custom classes too and I wouldn't want to throw that design all out unless it
halts me from moving forward in a bigger design. What is the gain in S1 world?
It's not like the DispatchActions are package-protected classes that no one can
access for their own use.
So I am not opposed to the enhancement in principal, but the justification is
iffy and it's a -0 for me right now.
> 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.
