+1 for this ----- Original Message ----- From: "Don Brown" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, December 01, 2004 1:00 AM Subject: Struts API Bean (was Spring dreaming)
> 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]
