Date: 2005-02-07T14:43:58 Editor: JoeGermuska Wiki: Apache Struts Wiki Page: StrutsChain URL: http://wiki.apache.org/struts/StrutsChain
Update to reflect big commit of chain changes. Change Log: ------------------------------------------------------------------------------ @@ -3,30 +3,23 @@ Some of the changes for this are fairly wide ranging, so it is risky to commit them to SVN until more is accomplished. We'll use this page to discuss implementation plans and questions, and to link to interim distributions. === What's in SVN === -The code committed to [http://struts.apache.org/acquiring.html#SourceCode SVN] is substantially similar to the old standalone struts-chain project. Here is a summary of the changes: +The code committed to [http://struts.apache.org/acquiring.html#SourceCode SVN] has started to diverge from the old standalone struts-chain project. Here is a summary of the changes: * Struts has been updated so that the ActionServlet initializes chain catalogs using the value of the init parameter '''chainConfig''', which should consist of one or more paths to XML files which can be processed by the standard Chain [http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/config/ConfigParser.html ConfigParser]. The paths may be either classpath resources or servlet context resources; the initialization process has methods for checking in both places without additional configuration. This and the changes to the RequestProcessor obsolete the CatalogConfiguratorPlugIn. If no '''chainConfig''' parameter is specified, then Struts defaults to looking for '''org/apache/struts/chain/chain-config.xml''' which is included in struts.jar. If any '''chainConfig''' value is specified, then if you also want Struts to use the default config, you must include it in the list of config files. * Struts has been adjusted to use the ComposableRequestProcessor by default. You may switch back to the original RequestProcessor by specifying it as the '''processorClass''' in the '''<controller>''' element of your '''struts-config''' file. By default, the ComposableRequestProcessor begins processing with the '''servlet-complete''' command in the '''struts''' catalog. This may be changed by specifying the '''catalog''' and '''command''' attributes in the '''<controller>''' element of your '''struts-config''' file. * You can now specify a chain command to be executed as part of any '''<action>''' element in a '''struts-config''' file. Simply include values for the '''catalog''' and '''command''' attributes. If a command is configured, then it will be executed before (or instead of) any action, forward, or include which is also configured in the '''<action>''' element. This effectively obsoletes the ChainAction class. Note that this functionality is '''only''' implemented in a chain command; if you revert to using the original RequestProcessor, these configuration values will be ignored. -=== What's under development === -JoeGermuska is working on implementing an ActionContext interface which clarifies the API with which Commands can interact with Struts. This class provides typesafe properties for all of the configuration values which are used by more than one command, and provides analogs for all of the methods which are part of the base Action class. + * The default chain has been reconfigured to be a bit simpler, and most importantly, to split processing into two sub-chains. These chains are "process-action" and "process-view", and while the default "process-view" chain is only "PerformForward", this seems to be a cleaner arrangement. It will also allow a command to terminate action processing early (such as when a form is determined to be invalid), saving later actions from the trouble of re-checking to see if the form is valid. + + * As part of this reconfiguration, the "process-action" chain is provided with an instance of a new interface, ActionContext. This allows the commands to use typesafe methods to extract values like the ActionForm and ActionConfig rather than having to rely upon +String constants and casting. This is something which still merits user feedback, as there are some questions about the best time and manner to construct an ActionContext, whether it should also be passed to the "process-view" chain, and whether it should even be made available outside of Struts in a final view handling technology like JSP or Velocity. -Code in the development builds includes a WrappingLookupCommand which creates a ServletActionContext class wrapping the current chain Context. It might be worth brief debate about whether it's safe to wrap the current context, or if instead the command which launches the '''process-action''' chain should copy values into and out of the context. The problem with the copying is that if users want to pass more values in, the copy process would have to be locally modified. - -''Another open question has to do with the current model where commands are separated into Abstract "web" classes and then concrete "servlet" subclasses. This model was designed to allow for portlet or JSF subclass Commands which share the same Abstract base classes. By warpping the initial Context in ActionContext, one can no longer cast to [http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/web/WebContext.html WebContext]. If we want to maintain the abstraction layer, then we need to choose a strategy. - -The strategy currently in the distributions (below) is to implement a WebActionContext class which has the same API as WebContext (which is an abstract class, not an interface.) I might be persuaded to simply move those properties into the base ActionContext, as they are basically just maps for the ApplicationScope, SessionScope, and RequestScope, all of which seem likely to exist in any Struts environment. It might also help with a question I have in the ActionContextBase regarding the modelling of scopes without any implementations. Perhaps they could be added as abstract methods and ActionContextBase made into an abstract class.'' - -(Since this wiki doesn't support strikethrough, I've italicized the above to indicate that it is becoming obsolete. I've come to appreciate the divisions between the Abstract and concrete classes. I've had one positive comment in favor of moving the accessors for the different scopes into the ActionContext API directly, and I'm leaning that way myself, allowing us to eliminate the WebContext class while still preserving the command abstraction layer.) +=== What's in Development === +At this time, there are no major initiatives; it would be good to get folks testing what's in SVN and flushing out bugs. Near-term tasks might be to adapt more of Struts to use the ActionContext API, helping to get out of direct dependencies on the Servlet API. Other suggestions are welcome, either on this page, or on the Developer mailing list. === Where can I get it? === -[http://www.apache.org/~germuska/struts-1.3.0-dev/ Non-SVN development builds] last updated 12-Jan-2005 06:09 AM (GMT-8) - -The archives available above are to output from a '''maven dist''' run against a local copy. These changes are not in SVN and are not meant for production use. They are provided to get feedback from interested parties. - -With the most recent build, the sample "mailreader" webapp appears to perform correctly in all cases. As this is a very simple app, more testing is definitely in order, as well as some consideration of the design implications. I'm hoping to have this ready to commit to SVN by around January 19th or so. +As of the nightly builds for 20050208, there is no major functionality which isn't readily available. You can get this code from SVN or from the nightly builds archives: see http://struts.apache.org/acquiring.html -Valiant testers are welcome! +Valiant testers are welcome! If you are interested, it would probably be good to join the developer's mailing list: http://struts.apache.org/using.html#Lists --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
