The public API bean (where the "rubber meets the road") could *not* be stored in application scope, since some of the Struts resources are request and session based.
The original idea was the ViewContext (fka ConfigHelper) would be created on a per-request basis (like a Velocity tool). The ViewContext might hold references to members in request, session, or application scope, but the ViewContext client doesn't need to know that. All of the tags and tools can then refer to the ViewContext, rather than having to know where all the "bodies are buried". The ViewContext interface could be based on the Velocity tools APIs (http://jakarta.apache.org/velocity/tools/struts/). I worked with these guys initially, and they are very tough about defining what you need, but no more. Internally, we might want to define an ActionContext that provides the same utility as the Action class and would also include the properties from the ActionForm. The idea being you could recode an Action class to use an ActionContext just by changing the references. Aside from the Action, we might also define a ResourceContext subset that could be shared with the business layer. The ResourceContext would include the messaging methods, so that the business layer could create Commons Resources messages (as part of a Command) and return them to Struts. This is an interface that we might define as part of the Commons Resources project, so that it is not tainted as a Struts import. Of course, the ActionContext would implement ResourceContext, so that we can exchange the same object with the business layer. All of these interfaces would implement Commons Chain Context (hence the suffix). The ActionContext could be called from an ActionCommand interface, a Chain Command-like interface with one method: void Execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. I would suggest we implement these interfaces as "experimental" in 1.3.x, so that we can work with them ourselves for a while. In 1.4.x, we could do things like refactor for Spring, and then finalize the new interfaces in 1.5.x. I know I should reduce this to code, but I'm away this week, and trying to keep a few balls in the air until I get back. Eventually, we may to put a collection of Controller beans in application scope, open per module. This might be a place where a BeanFactory might be useful, but I think there are some other issues we need to iron out first. (Else start the revolution!) -Ted. On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown wrote: > On the topic of a Struts API bean, I completely agree. We should > have one bean, probably actually stored in the servlet context, > which contains references to all the Struts-specific components > like configuration elements and message resources. Now this, and > the Spring topic, do overlap since this API bean could actually be > a Spring BeanFactory which might be a more flexible approach > actually. > > This would be separate from the ActionContext idea which would hold > references to objects necessary for the execution of actions (chain > context, http request/response, all current Action helper methods, > etc). > > Ted, in fact, suggested an API bean previously as well, and I > believe has even started sketching out what one might look like. > > Don > > Joe Germuska wrote: > >> While I'm one who has had good experiences with Spring's >> BeanFactory for managing my business objects, maybe we should >> focus first on defining what Struts is and what needs to be >> configured. This would allow us to move more flexibly to various >> configuration approaches, or conceivably support more than one. >> >> I've been thinking for a while that we should stop storing so >> many things directly in the ServletContext and instead, define a >> "Struts" object which would hold these things. I've mentioned >> this obliquely a few times and not gotten much response, so maybe >> no one else likes the idea. Or maybe it's been too oblique. >> Benefits of something like this would be reducing dependencies on >> the Servlet API and providing a better environment for testing. >> >> Is there any interest in this, or is it cracked? If it's not >> cracked, we might also take a longer-term look at abstracting the >> session, which seems tedious, but has some of the same issues. >> We may never need to truly abstract away the HttpServletRequest, >> since the Chain context will have the same lifecycle and serve >> about the same purpose. >> >> Now, then: This whole thread started as a different question and >> was motivated by an earlier question. Assuming that we continue >> to use Digester to instantiate and populate ActionConfig objects, >> I would like to add a "generic" mapped property to ActionConfig >> so that rather than writing trivial and boring subclasses of >> ActionConfig, one can simply set properties on it. I'd make it a >> Properties because I'd expect it to have strings, but I would >> accept arguments to make it a map instead with the idea that >> later other Objects might get in there. (Ugh, but all that >> casting!) Assuming no one objects in the next day or two, I'll >> assume it's ok, and I'll call it "props", just because I would >> rather not screw around waiting for another name. >> >> The motivation for this was a perceived flaw in the ChainAction >> and chain DispatchAction classes which won't know in which >> catalog to look for the command either one is supposed to >> execute. A generic property map would allow the ChainAction to >> define the name of the properties it wants for its configuration, >> rather than requiring that its ActionConfig implement some >> specific interface just to get one more property in. >> >> Joe > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
