On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska <[EMAIL PROTECTED]> 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.
+1 for defining a context, reducing servlet API dependencies, and making the framework more testable. :-) -- Martin Cooper > 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 > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
