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]
