> That's a good point. Start simply by making ActionContext have > bean 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? Perhaps it should be based on the Chain Context, which has implementations for various platforms. * http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/Context.html The request, session, application, and cookie contexts could all be contexts within the ActionContext. If an application didn't need access to special services (and many don't), this could make it possible for people to write "POJO". But, if they needed platform services, they could cast it whatever platform they expect be using. 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 Views could then look to the StrutsContext for whatever they needed from us, rather than poking around in the various scopes. Eventually, this could open the door to having multiple Struts Controllers. Each module could have their own controller filter or servlet, and we wouldn't have to support all the "special case" code. The servlets and filters already have cannonical names in the web.xml. These could be keys into a master context. When the request passes through, the context for it's controller is added, and we proceed from there. -Ted. On Fri, 29 Oct 2004 12:18:32 -0500, Joe Germuska wrote: > Well, I've mentioned before that I find an ActionContext appealing. > That's a good point. Start simply by making ActionContext have > bean properties for the four objects normally passed into execute? > > I think we'd want to have a factory process for getting instances > of the ActionContext, because the way we use it, we put lots of > things specific to our app design in there as well. > > In a Chain world, that could just be a command found using the > "lookup" functionality, with a default lookup which just made a new > instance. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
