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]
