> That's a good point. Start simply by making ActionContext havebean properties for the four objects normally passed into execute?
Someone mentioned they were already using an ActionContext in their own apps. Was it you, Joe?
Yes, we use this as the basis of our most recent app, and I've been experimenting with it for a while. We have a base dispatch-type action which creates the ActionContext and invokes a method which takes it as the signature.
There are risks of taking too much advantage of having a lot of information packed into this one object -- you might pass it everywhere and end up writing things more tangled than perhaps they should be. But then, it also makes it easier to extract methods, which is a refactoring of which I'm particularly fond.
We've also added a few utility methods to the ActionContext based on the fact that it has direct access to the request: for instance, a few variations of "addMessage" and "addError" which manage a pair of ActionMessages objects internal to the ActionContext. Also a "findForward" method which just avoids continually chaining context.getMapping().findForward(). I can imagine that adding behavior to a context clas vs. keeping it lean and just a container for references could be a heated discussion -- but as long as there's a factory process allowing folks to specify an alternative ActionContext implementation, then there need be little argument.
Perhaps it should be based on the Chain Context, which has implementations for various platforms.
I've thought about this, but I've also had reservations about separation of concerns. I haven't thought very hard about it, so I'll wait until I have before I try to decide how I feel about it. When you suggest that, then I wonder why we wouldn't just throw away Actions all together and just have people write Commands instead. One reason would just be not to change too much on people all at once, which is a pretty good reason, I guess.
What I'd like to work towards is passing an ActionContext around the controller and then passing a StrutsContext out to the view.
The StrutsContext would be an "API bean", like the one contemplated here.
* http://struts.apache.org/api/org/apache/struts/config/ConfigHelperInterface.html
Yes, I like this.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
