Hi, Joe,
Awesome! Can you wax eloquent on what the use of the ActionContext is here? What "values" do you mean? I assume you mean values associated with the instantiation of various Struts classes? I don't know what you mean, obviously.
(First, the answer; later, the update on today's build.)
OK, what is the use of ActionContext? The main point is to articulate the Struts API and insulate Struts classes from dependencies on other APIs. There are many places in Struts where the Servlet API is built-in, which makes Struts hard to adapt to use in Portlets, let alone Web Services.
What I'm working on now is a ServletActionContext implementation of the ActionContext interface. In places where Struts *needs* ActionServlet, HttpServletRequest, HttpServletResponse, HttpSession, etc., it can cast the ActionContext to ServletActionContext and get them. But by making this explicit, we should be able to catch ourselves and be much more careful about permitting those kinds of dependencies. Getting the feel for this has also made me much more tolerant than I had been of the split between the Abstract classes in the o.a.struts.chain.commands package and their concrete children in o.a.s.c.commands.servlet.
Also, by adapting the commands to expect to receive an ActionContext class, I was able to simplify the command classes considerably. The original implementations have lines and lines of bean property code to allow you to configure from the chain-config.xml the locations of the various things the command needs to get out of its context (ActionConfig, ActionForm, Action, the result of form validation, the result of form cancellation, etc...)
Even though bean properties are conceptually simple, I think the lines and lines of code removed makes things much more straightforward; furthermore, the emerging concept of a ContextWrapper means that you could just write your own Wrapper if you were going to have a context which occasionally stored these things in non-standard locations.
Now, the update: the build posted this morning actually works all the way through the mailreader app, and seems to handle everything in it. The mailreader app is pretty simple, and I strongly suspect that some of the changes I had to make to get it all running need to be done more generally -- these are basically to do with where the ServletActionContext implementation puts things.
I think I am leaning towards having it read and write values into the request or session in a way more directly compatible with existing Struts practices, as it's least likely to have surprises -- however, this sacrifices the "Attribute-Property Transparency" which is strongly recommended in the design of Context (http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/Context.html).
There's probably a way to test both the internal Context as well as the request or session, but I'm not sure whether there's a responsibility to copy values from the request into the internal context if they are used as a fallback. I'm not even sure how to articulate this to anyone who hasn't been thinking about the problem! Is anyone following me?
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]
