--- Ted Husted <[EMAIL PROTECTED]> wrote: > 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.
I like the one api bean approach because then you don't have to remember the names of the objects to lookup in the context. You just remember one name and get the rest from that bean. We don't need a migration path if we do this for 2.0, only for the 1.x series. I'm not sure which series you were planning on doing this in though? David > > -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] > > __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
