- 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.
- 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
The sample app code incl. environment (Eclipse 3.1M4 etc) is there at http://sourceforge.net/projects/infonoia/
I will see that it gets updated tomorrow based on the nightly build of tonight's svn.
Best regards, Wolfgang Gehner
Joe Germuska wrote:
I have just committed the suite of changes I was emailing about a few weeks ago. Please be aware that nightly builds are probably now the least stable that they've been in some time. I have spent some time this weekend working on a simple site using the new code (including struts-taglib and struts-tiles jars build from SVN head) and things aren't horribly broken, but there may be some quirks. Odds are good that most of them have to do with the ServletActionContext class not always putting things in request scope that JSPs or utility classes are accustomed to retrieving from the request scope. I find it kind of odd to store things in both places, but it seems like a necessity for a while for backwards compatibility.
I hope to continue using this code as I begin prototype work on a new project, but of course, the more people who can get their hands on this code, the better.
This also installs the "split" between the "process-action" and "process-view" sub-chains, although I haven't yet changed the SelectInput command to return "false" to eliminate the need for later commands to check to see if the form was valid.
I think the big outstanding question in my mind now is what kind of context we want to pass into the "process-view" subchain. In some earlier discussions, there was talk about a "ViewContext" -- I haven't touched that at all, but I'm whether it's worth distinguishing that from the ActionContext. As it is now, I have my own command which sometimes gets used in the view chain and sometimes in the action chain; as it is now, I have to test whether the context is an ActionContext or a ServletWebContext -- I need to get to the request parameters and scope/map, and by not using the ActionContext in the view, it seems more awkward than it should be.
It would be pretty easy just to change the chain-config.xml file to use the new WrappingLookupCommand so that the same ActionContext gets sent into both "halves," but I didn't want to do that just yet. I'd like to hear if anyone has justifications for a different kind of context for a "ViewContext" (noting that I have one real use case where the same command is used in both sides, so a ViewContext would be just as awkward as what I have now.) I was also wondering whether we ought to routinely put the context into the request scope so that that object is available to view technologies like JSPs and Velocity templates. It seems like it would be handy.
So, for the brave, please dive in and start trying to apply the SVN head to some applications and help to flush out anything that's not quite right...
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
