Cool. If it doesn't do what you need (like access the velocity context or velocity engine), you can bet one of the other tools probably does.
On Jan 16, 2008 10:03 PM, Gary Bentley <[EMAIL PROTECTED]> wrote: > Thanks for that Nathan, I'll probably use the LoopTool as a template, it > appears to have the items you are talking about. > > Gary > > > > Nathan Bubna wrote: > > On Jan 16, 2008 2:27 PM, Christopher Schultz > > <[EMAIL PROTECTED]> wrote: > > > >> Gary, > >> > >> Gary Bentley wrote: > >> > >>> For the class name, it's needed because during the parse it uses the > >>> class name to resolve method/field accesses. Without it resolution > >>> would be needed at execution time. In theory it's not needed but it > >>> also allows the query to be parsed into the relevant tree of objects so > >>> that it can be reused for execution. > >>> > >> Gotcha. > >> > >> > >>> It also has the benefit of making > >>> the query more readable to humans, so if you pass the query around > >>> others can tell what class it is operating on. > >>> > >> When I was reading the "quick description" on the website, I was > >> confused at first because it wasn't clear that a collection of existing > >> objects were being passed-in as a context to evaluate the query (until I > >> kept reading, of course). At first, I thought that "SELECT * FROM > >> java.io.File" would magically read from the filesystem. Silly me! > >> > >> > >>> There is one issue, you > >>> said that the tool is put into the application scope, however JoSQL > >>> isn't thread safe, is it possible to get the tool to be created per > >>> thread? (I could however use a query pool and normalize the query > >>> string if not) > >>> > >> That's really up to you. Velocity Tools itself will not create a new > >> tool per thread, but you can specify that a tool should be > >> request-scoped (that is, a new one is created for each request). Since > >> Velocity Tools was really created for webapp-use, and webapps should > >> only use a single thread for each request, this works out just fine. > >> > >> If the JoSQL processors are not thread safe, you can simply direct your > >> users to specify "request" scope when configuring the tool in the > >> Velocity Tools toolbox. > >> > > > > Definitely use request scope if there's any thread safety concerns. > > With VelocityTools 2.0 (still in beta, but final release is largely > > waiting on feedback and finishing docs), you can even add a > > ValidScope(Scope.REQUEST) annotation to your tool class, to prevent > > users from using the tool in any other scope. Also, if your tool will > > be needing access to the current context (in VelocityTools 2, just add > > a setVelocityContext(Context ctx) method and it will automatically be > > given to the tool each request), then be sure to use request scope. > > > > (Apologies for all my not-so-subtle plugs for VelocityTools 2; i want > > to be sure people are motivated to upgrade from 1.4 soon :) > > > > > >>> I do have plans for a future enhancement to allow a bind variable to be > >>> used of a class name instead so that it can be more dynamic. > >>> > >> Speaking of bind variables, I found myself a little thrown by their > >> syntax for the simple reason that it differs from JDBC. Perhaps you > >> could offer separate parsers at runtime for those who prefer the > >> JDBC-style syntax. > >> > >> Good luck, > >> -chris > >> > >> > >> > > > > > --------------------------------------------------------------------- > > 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]
