[Struts Wiki] Update of StrutsAction1Planning by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsAction1Planning New page: = Struts Action Framework 1 Planning = This page collects ideas and discussion on what could be included in future releases of Struts Action 1. This page is a whiteboard, meaning no one has committed to anything and therefore its purpose is to share information and brainstorm. == 1.3.x and beyond == The 1.3.x series utilizes Struts Chain as the default request processor and adds an extends attribute to all the configuration elements (a la Tiles). We would also like to add a Ant-style properties file to make variable substitutions within the XML elements. The substitution feature is supported by Spring and iBATIS, among others. Substitutions are a useful way to configure applications and reduce redundancy. == Experimental Members == To lay the groundwork for future changes, three experimental classes and interfaces are being added to the framework so that early adopters can experiment with using Struts Chain to develop applications. We do consider these members experimental, and they are subject to change, based on our experience using them with our own applications. '''ActionCommand''' - A Chain Command-like interface with one method: void execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. '''ActionContext''' - A Chain Context that implements the logical Action class API. Existing code could be converted by changing references to context.* and so forth. The context could be constructed by the Request Processor, as an optional Command in the Chain, so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface. '''ViewContext (pending)''' - A Chain Context that implements the logical Velocity Tools API. In a later release, when the new members stabilize, we could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.) After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3.x, they could be marked experimental. The Commons Chain WebContext we now pass around Struts Chain could be called the StrutsContext to differentiate it from the ActionContext and ViewContext. (Are we now starting to call everything Context instead of Action? Not really. We use the Context suffix when a member extends Chain Context. This convention is unlike the current Action soup, since Context is a suffix that identifies a member's family history.) Another experimental member is the catalog element, which could be used to to support using a Chain of ActionCommands in lieu of an Action. == Struts Action Framework 1.4.x considerations == One we get past 1.3.x, there are some other things that we might consider. Consider combining DTDs. Right now, using standard extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration. Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground. == Struts Action Framework 1.5.x considerations == Based on our own work with the experimental members introduced in 1.3.x, we might consider some other changes. '''Consider a smart action type'''. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even try placing an ActionCommand interface on ActionForm, so people could skip having a seperate Action or ActionCommand class. The ActionForm could do it all. '''Consider a populate method on ActionForm'''. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on a god class to populate it from
[Struts Wiki] Update of StrutsAction1Planning by DonBrown
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsAction1Planning
--
To lay the groundwork for future changes, three experimental classes and
interfaces are being added to the framework so that early adopters can
experiment with using Struts Chain to develop applications. We do consider
these members experimental, and they are subject to change, based on our
experience using them with our own applications.
- '''ActionCommand''' - A Chain Command-like interface with one method:
+ '''!ActionCommand''' - A Chain Command-like interface with one method:
-
+ {{{
void execute(ActionContext context)
+ }}}
Support for conventional Actions would stay in place, but as an alternative,
a class could implement ActionCommand and unbind itself from the HTTP API.
- '''ActionContext''' - A Chain Context that implements the logical Action
class API.
+ '''!ActionContext''' - A Chain Context that implements the logical Action
class API.
Existing code could be converted by changing references to context.* and so
forth. The context could be constructed by the Request Processor, as an
optional Command in the Chain, so that it could be exposed this through
thread-local, opening the door for POJO actions that don't implement a
particular interface.
- '''ViewContext (pending)''' - A Chain Context that implements the logical
Velocity Tools API.
+ '''!ViewContext (pending)''' - A Chain Context that implements the logical
Velocity Tools API.
- In a later release, when the new members stabilize, we could move the taglib
dependencies from the servlet contexts to the ViewContext. View technologies
could then look exclusively to the ViewContext rather than poke around in the
various servlet contexts. (Of course, support for the original architecture
would remain for some time, to give third party libraries the chance to
migrate.)
+ In a later release, when the new members stabilize, we could move the taglib
dependencies from the servlet contexts to the !ViewContext. View technologies
could then look exclusively to the !ViewContext rather than poke around in the
various servlet contexts. (Of course, support for the original architecture
would remain for some time, to give third party libraries the chance to
migrate.)
- After having a chance to work with ActionContext and ViewContext ourselves,
we could introduce more support for these members in a later release. But for
1.3.x, they could be marked experimental.
+ After having a chance to work with !ActionContext and !ViewContext ourselves,
we could introduce more support for these members in a later release. But for
1.3.x, they could be marked experimental.
- The Commons Chain WebContext we now pass around Struts Chain could be called
the StrutsContext to differentiate it from the ActionContext and ViewContext.
+ The Commons Chain !WebContext we now pass around Struts Chain could be called
the !StrutsContext to differentiate it from the !ActionContext and
!ViewContext.
(Are we now starting to call everything Context instead of Action? Not
really. We use the Context suffix when a member extends Chain Context. This
convention is unlike the current Action soup, since Context is a suffix
that identifies a member's family history.)
- Another experimental member is the catalog element, which could be used to to
support using a Chain of ActionCommands in lieu of an Action.
+ Another experimental member is the catalog element, which could be used to to
support using a Chain of !ActionCommands in lieu of an Action.
- == Struts Action Framework 1.4.x considerations ==
+ == Struts Action Framework 1.4.x considerations ==
One we get past 1.3.x, there are some other things that we might consider.
- Consider combining DTDs. Right now, using standard extensions like Tiles
and Validator mean using more than one configuration file. While using multiple
configurations files can be a good thing, we should also try and support the
idea of having a single configuration file. This might not work-out for Tiles,
but we might be able to at least integrate the Validator configuration with the
DynaForm configuration.
+ Consider combining DTDs. Right now, using standard extensions like Tiles
and Validator mean using more than one configuration file. While using multiple
configurations files can be a good thing, we should also try and support the
idea of having a single configuration file. This might not work-out for Tiles,
but we might be able to at least integrate the Validator configuration with the
!DynaForm configuration.
- Consider refactoring for Spring. We identified the need for adding a IOC
container to Struts some time ago, but stalled on the point of which to use.
Since then, Spring
