The problem is that one developer's litter is another developer's treasure :)
Right now, a lot of components are already pointing to the components we've scattered about the contexts. If we just move them into our own context, then those references would break. To create a migration path, we'd first have to provide an ViewContext to replace direct access to the components, deprecate direct acess, and then, in a future release, move the components our own state mechanism. -Ted. On Thu, 02 Dec 2004 09:35:47 -0800, Don Brown wrote: >�I agree with everything you wrote, however, what I was specifically >�talking about was some sort of storage bean that all the global >�Struts components could be stored in, so we don't have all these >�Struts objects littering the servlet context. �Yes, for each >�request, a ViewContext instance would be created, initialized with >�this storage bean. > >�Don > >�Ted Husted wrote: > >>�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: dev- >>>[EMAIL PROTECTED] For additional commands, e-mail: >>>[EMAIL PROTECTED] >> >> >>�------------------------------------------------------------------ >>�--- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
