On Jan 17, 2008 7:34 AM, Christopher Schultz <[EMAIL PROTECTED]> wrote: > Gary, > > Gary Bentley wrote: > > Actually, just so I know could you let me know what the life-cycle is > > for tool objects? Is a new tool object created per request and > > hence discarded after the request has been made. Or is a pool of > > objects created and then an object assigned from the pool to each > > request? > > No pools AFAIK: you get a new object per-[scope]. If it's application > scope, then the object gets created at webapp startup and lives for the > life of the app. Same for session or request. Actually, I think VelTools > 2.0 does lazy loading so you won't get a JoSQL object for a particular > request if none is ever requested.
Just to clear up a little grammatical ambiguity above, the request or session tools do not live for the life of the app (as could be read above), but rather for the life of the request or session, respectively. And yes, VelocityTools doesn't pool, it's just not worth the overhead for most tools. And yes, VelTools 2 only loads tools when they're used. > > I am trying to avoid the relatively costly statement parse, but I > > think it may be unavoidable anyway since to identify the relevant > > Query object (that will do the actual work) I would have to parse and > > then normalize the query string anyway. > > I think what you want to do is parse the query string on demand, and let > the template author figure out the rest. > > Finally, don't forget that a tool instance does not equal one of your > query instances. You could write a tool that creates a new query for > every single "request" made to the tool. In that case, you don't have a > threading issue (but may have a performance issue). If you wanted to be > really anal about it, you could keep a cache of query string -> query > objects in your tool, though i doubt very much it would be really worth > it. Parsing those queries shouldn't take /that/ long. > > Honestly, I think the explosion of "tools" for velocity is starting to > look like ColdFusion where everything is a view tag instead of being put > into the controller like it really should be. :( we've never claimed to be an MVC purists. :) MVC is just another pattern that is ideal sometimes, ok sometimes, and just unnecessary sometimes. it's not hard to ignore any tools you don't like. > I realize that you are simply trying to cater to your users, but I'm not > sure if this tool is really in their best interest. nor could you be sure. ;) there are many different apps and needs out there. and many perfectly reasonable and helpful ways of developing them. > > -chris > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
