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 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. + 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 "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 the outside. + '''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 the outside. - '''Consider a "FormContext" mechanism'''. Rather than "throw-away" a request-based ActionForm, the object could be seralized as a hidden-field or session-object and restored on the next request. Many other frameworks support this behavior now. Struts would have a slightly different spin, since we look at the form as an named entity rather than as an anonymous aggregation of other objects. + '''Consider a "!FormContext" mechanism'''. Rather than "throw-away" a request-based !ActionForm, the object could be seralized as a hidden-field or session-object and restored on the next request. Many other frameworks support this behavior now. Struts would have a slightly different spin, since we look at the form as an named entity rather than as an anonymous aggregation of other objects. Struts Action Framework 1.6.x considerations - '''Consider multiple controllers'''. One reason we introduced modules was because "there can only be one" Struts controller in an application. With the context-based changes we making, we might be able to introduce a mechanism to support a collection of Struts controllers, each identified by its servlet or filter name, each with it's own URI pattern. The key to being able to do something like this is for view members to look to the ViewContext rather than the various servlet contexts. Each Struts controller would place the appropriate ViewContext in its own requests. + '''Consider multiple controllers'''. One reason we introduced modules was because "there can only be one" Struts controller in an application. With the context-based changes we making, we might be able to introduce a mechanism to support a collection of Struts controllers, each identified by its servlet or filter name, each with it's own URI pattern. The key to being able to do something like this is for view members to look to the !ViewContext rather than the various servlet contexts. Each Struts controller would place the appropriate !ViewContext in its own requests. '''Consider an alternate configuration file'''. There are idiosyncrasies in the element/attribute names of the struts-config which often confuse new developers. By either supporting alternative configuration loaders, or applying a stylesheet to a XML configuration, we could support both the "classic" and a new configuration (based on something like Struts Jericho ). @@ -61, +62 @@ There are three major issues with supporting JSR-168 (and probably a bunch of smaller ones as well): - * The framrwork APIs assume servlet API objects (ServletContext, ServletRequest, ServletResponse), whereas JSR-168 talks about PortletContext, PortletRequest, and PortletResponse. We'd either need to change the calling sequence for Action.execute() -- problematic for backwards compatibility -- or fake it somehow in a portlet environment. + * The framrwork APIs assume servlet API objects (!ServletContext, !ServletRequest, !ServletResponse), whereas JSR-168 talks about !PortletContext, !PortletRequest, and !PortletResponse. We'd either need to change the calling sequence for Action.execute() -- problematic for backwards compatibility -- or fake it somehow in a portlet environment. * The lifecycle of a portlet request is actually divided into two chunks -- processing and then rendering. From a Struts perspective, that means making sure that the first part of the request processor pipeline need to happen in the "process" part, and the forwarding to the resulting page needs to happen in the "render" part. * Today, Struts owns the process of calculating URLs for pages and actions. Because it's in a webapp, it knows exactly what to do for the developer. However, in a portlet container it's actually the portal server that manages URLs, so a Struts-based portlet would need to interact with the portlet APIs for this purpose. @@ -76, +77 @@ * Struts Jericho * Struts Shale * Struts Ti - * Struts OverDrive + * Struts !OverDrive --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
