Ok, I think I understand the use case, and using a map is definitely
cleaner than what I had done in the struts2 plugin - create a "wrapper"
for the actual context which allowed me to inject my own defaults (see:
http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/tiles/src/main/java/org/apache/struts2/tiles/ConfiguredServletContext.java)
<rattling off the top of my head>
I still think that ideally we'd only provide one of the two, but
unfortunately, we can't remove the context in lieu of the map, because
then we won't have it to create the context factory, and the opposite
isn't that nice either.
Also, I still wonder if what's provided in the map are really defaults,
or if it's just a different way to provide "custom" behavior.
</rattling off the top of my head>
I don't really have any better ideas, I was just curios what your
thoughts were. . . I'll think about it a little harder and see what I
come up with.
David
Antonio Petrelli wrote:
David H. DeWolf ha scritto:
Antonio,
I'm not sure I understand why we need to support both the context and
a map of defaults for retrieving config info for factories. It seems
redundant and thus confusing.
If we want to use a map, shouldn't we just remove the context all
together and have the client push all of the init parameters into the
map prior to invocation?
I made that change (the use of "custom" defaults) because some container
"creators" (such as the TilesPlugin for Struts 1) need to have default
classes when they are not specified explicitly.
In particular, in the TilesPlugin I am wrapping the plugin context and
the ServletContext as a unique ServletContext (giving precedence to the
plugin context init params).
Now, if the Struts application is configured to use modules, it will use
the "keyed" container as a default, otherwise it will use
BasicTilesContainer (this is what I have in mind, there is no code
currently in the Struts-Tiles2 plugin).
So I decided to use a custom "defaults" map. I thought also to provide a
"default" class inside the ServletContext provided by TilesPlugin, but
the code could become a bit messy.
This was I was thinking when I made those changes, anyway if you have a
better idea let me know.
Thank you
Antonio
---------------------------------------------------------------------
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]