- Based on *last weeks* code, we created our own context named "ActContext" that extends ServletWebContext, so we could add convenience methods on it that keep our action code clean (like we want to get the bean in scope by calling "getBean" on the context, "getIDParameter" to get a request parameter named "ID" we use as rowId etc etc) With tonight's svn, it could probably extend ActionContext. To plug it in, we extended ComposableRequestProcessor. I suspect that extending the default context will be a pretty standard thing to do, so it might be a good idea to allow this:
<controller processorClass="org.apache.struts.chain.ComposableRequestProcessor" contextClass="aaa.bbb.ccc.MyContext"/>
Switching contexts within the request cycle would make all this more difficult.
I agree that extending the default context will be a common use case. As I implemented, you'd do this by changing the default chain config, specifying a different ContextWrapper class for the WrappingLookupCommand.
I thought about putting this in the controller instead, but the general idea of a WrappingLookupCommand seemed useful enough. I was leery of adding too much config to the base struts config until I felt that some of the design ideas were more widely vetted.
Also note that ActionContext is an interface, although there is an ActionContextBase implementation which extends ContextWrapper and should provide a pretty straightforward starting point for any non-servlet Struts implementation. Portlet implementations could extend WebActionContext, and Servlet implementations could of course extend ServletActionContext.
Unfortunately, all of the concrete implementations of the chain commands have dependencies on the Servlet API, but that's just a legacy of Struts own dependencies. I'm hoping that we can begin to make changes to use the ActionContext class in signatures which previously depended on Servlet API classes. As we do that, we may be able to push more and more behavior into commands which only depend on Struts' own API.
- We also created a DispatchCmd that is modeled after DispatchAction, so commands that extend it can have methods like "save(Context context)" when the url is /do/testCmd?method=save
Note that there is a DispatchCommand in the nightly builds of commons-chain also; no one has talked much about a release, but it's there for those who are interested.
Thanks for the quick feedback!
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
