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]

Reply via email to