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.
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. :( 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. -chris
signature.asc
Description: OpenPGP digital signature
