On 2/25/07, Claude Brisson <[EMAIL PROTECTED]> wrote:
Hi there!Here are some structural evolutions I'd like to discuss before any coding. I'm pretty sure that the first one is a good option - the second one is more prospective. 1. On-demand tools loading: instead of a standard HashMap, the idea here is to have a ToolMap, inheriting HashMap, which will instanciate a tool from its toolinfo only when the generic getter is called. This should be a quite interesting performance gain in some situations. We maybe need some attribute to have tools instanciated at toolbox initialization ('instanciate-on-load' ?).
I really like the idea! Though, i think i might prefer to call it a Toolbox instead of ToolMap. just to stick with the metaphor... :)
2. View tools: other objects in my webapp are often jealous of the view servlet. They also would like to use some of the tools. Session scoped tools can be reached via the session, but it's not the case for application or request scoped tools. To achieve this, there would be two things to do: - the application tools map should be stored as a ServletContext attribute and the request tools map as a Request attribute. - the constitution of the three scoped maps should be decorrelated from the remaining of the processing so that it could potentially take place in a servlet filter.
i agree we should find a way to solve this, though i'm not sure i fully understand the second part of your proposed implementation. i would think we would simply want to create a Toolbox (as in idea #1) for each scope, place the proper Toolbox in the attributes of the request/session/servletcontext and then just make our ChainedContext smart enough to search in all of those for tools that are requested. i don't see why we need a filter or to constitute the three toolboxes at all. oh, and with this, we may want to re-organize the layout of a toolbox.xml file to lump the tools from the three scopes together in their toolboxes. but that's a separate issue... i predict there are going to be some interesting complications/side effects, but we'll be able to see those better once we start coding. i'll try and get a 2.x branch set up today (or soon, if i don't get to it). Then we can start hacking away. i have some other ideas and major changes in mind and already have some code for them too. i'm excited about the possibilities...
Thanks for your remarks, Claude --------------------------------------------------------------------- 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]
