[
https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40221
]
Michael Jouravlev commented on STR-2940:
----------------------------------------
The reason is to finally make event handling a core feature of Action. Does it
take Stripes to understand the benefits of handling several kinds of request in
the same Action?
I would like to shift the mindset from "one request - one action - forward to a
page" to a code-behind ideology. Compare with ASP.NET, the code-behind has
event handlers for all buttons on the form, why Action cannot have the same
features? I've been promoting code-behind approach for about two years. Does
not Don currently promotes a similar approach for Struts 2?
Historically action-based and page-based frameworks have been treated as having
different sets of benefits and drawbacks. I believe that an action-based
framework can have all the benefits of a page-based framework while keeping the
flexibility of Model 2. With new Action one will be able to use whatever
approach he likes, be it a servlet-like one-request-at-a-time or
web-resource-oriented code-behind approach.
Action will still remain nice, simple and light-weight if event-related
attributes are not specified in a mapping. And by the way, combining doGet and
doPost into one perform/execute does not seem nice, simple and light-weight to
me, it appears more like cutting a perfectly functioning leg. Event handling
feature is somewhat like replacing the missing leg with multiple new ones.
> 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.
