[
https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40222
]
Frank W. Zammetti commented on STR-2940:
----------------------------------------
I'm not arguing what your trying to do... I'm simply asking two intermingled
questions here:
Why does what your trying to do have to involve modifying Action? Why isn't
simply creating a new kind of Action sufficient?
I imagine that when DispatchAction was first introduced, a similar question was
asked... why not just add dispatching functionality to Action and be done with
it? Well, somewhere along the line, someone decided a second kind of Action
was the better answer. I'm asking the same question here, not debating whether
what your proposing is a good idea or not. It seems to me, if it's a new
descendant of Action, then that question is moot anyway.
If your only goal is to push a new mindset on people, which frankly seems to be
the case based on what you said in the previous comment, I would contend that's
not the right reason to do this, considering the tremendous number of existing
Struts apps that have to be maintained.
A related piont, although one I hesitate to make frankly... One could certainly
make the argument that S1 is quickly becoming legacy given the advent of S2,
and in that frame of mind, I don't think major architectural changes (which
this is, whether developers are forced to deal with it or not) should be
undertaken lightly.
> 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.
