On 2/26/07, Nathan Bubna <[EMAIL PROTECTED]> wrote:
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...
ok, so i started working on this last week, and got further than anticipated. this week, i've had a little time to refine some things, so i want to start checking stuff in a bit later today. i've probably already done more than i ought to have without checking stuff in. at this point, i'm not thinking extensively about backwards compatibility, but i do hope to address that eventually. i just wanted to give a little heads up that some of this stuff is going to start coming into the 2.x branch today. also, please note that it compiles with jdk 1.5 and velocity 1.5, but is not yet fully useable nor have i written tests for the new stuff yet. i do plan to write tests, and i'm thinking about jdk 1.4 support as well. i'm not planning to support pre-1.5 Velocity though. feedback is welcome, as are contributions. oh, and in case anyone is concerned, i have no plans to stop developing the 1.x branch. i'm just exploring the possibilities for 2.x.
> 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]
