Date: 2005-01-12T07:58:39 Editor: JoeGermuska Wiki: Apache Struts Wiki Page: StrutsChain URL: http://wiki.apache.org/struts/StrutsChain
update with info about latest build. Change Log: ------------------------------------------------------------------------------ @@ -15,16 +15,18 @@ 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. +''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. +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.) === Where can I get it? === -[http://www.apache.org/~germuska/struts-1.3.0-dev/ Non-SVN development builds] last updated 10-Jan-2005 20:08 (GMT-8) +[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, it seems that things basically execute. There is a decent chance that things are not all going into the right places, especially into the request or session. The main goal of the ActionContext is to steer towards having all references go through it, minimizing the number of places where request and session attributes are handled directly, but for backwards compatibility, it is expected that resources will be stored in both places for a little while. +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. Valiant testers are welcome! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
