Re: Default to quiet references
Andy Lee wrote: I know you're asking about adding a configuration option to the language, but have you considered using a macro? Something like: $foo ## never quiet $!foo ## always quiet #qu( $foo ) ## quiet iff $forceQuiet is true #qu( $!foo ) ## doesn't make sense to use Thanks for the suggestion, but I'm really just trying to keep it easy for the users. I think $!foo would be easier than #qu( $foo ), so assuming it's not possible now, I'll go hack something myself and submit a patch if desired. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com -- To unsubscribe, e-mail: mailto:velocity-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:velocity-user-help;jakarta.apache.org
Re: FreeMarker, Velocity, Jonathan, me :)
Dave, I would start by subscribing to the velocity-dev list and reviewing what's in bugzilla. Also check out http://www.apache.org/dev/ for advice and tips on how to contribute. If you can confirm validity of old patches and write some patches for some of the existing bugs, hopefully you can get nominated as a committer before too long. In this situation, I would think sustained interest and availability is all you need. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Layered resource caching
I've defined 2 resource loaders, basically a set of customized templates with a set of default templates underneath it. Most of the time it works great... if I ask for foo.vm, it first checks the customized template folder, and if not there, it falls through to the default template folder. My one problem is when the template has already been loaded from the default template folder, and I add one to the customized template folder. The default template loader does not refresh the resource, since that file timestamp has not changed. What I'd like is the resource manager to check the customized template folder first before turning to the default template folder, and ideally still use a cached version for that. Is the only way to do this to write my own ResourceManager implementation, or is there another way to do this? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Layered resource caching
Shinobu Kawai wrote: What I'd like is the resource manager to check the customized template folder first before turning to the default template folder, and ideally still use a cached version for that. Is the only way to do this to write my own ResourceManager implementation, or is there another way to do this? Which loaders are you using, and how are you configuring them? I think one FileResourceLoader with multiple paths should do the trick. (Haven't tried, though) resource.loader=file1,file2 file1.resource.loader.class=org.apache.velocity.runtime.resource.loader.FileResourceLoader file1.resource.loader.path=foo file1.resource.loader.cache=true file2.resource.loader.class=org.apache.velocity.runtime.resource.loader.FileResourceLoader file2.resource.loader.path=bar file2.resource.loader.cache=true Put a template into bar and have Velocity try to render that template. Then put a template with the same name into the foo directory, and you'll continue to get a copy of the bar version. If you restart Velocity, you'll then see the foo version since that appears earlier in the resource loader. I guess you're saying that the file loader has this ability built-in, but I'm using a mixture of resource loaders and am using the multiple loader feature, so I need the resource manager to handle this. Again, it seems like I need my own ResourceManager impl, but just wondering if anybody hit this before, had a better suggestion, or a planned work around. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Immutable pojos as context objects
I was wondering if there is a convenient way to restrict method calls on objects I put into VelocityContext. I use Velocity templates to do dynamic renders high-traffic websites, and I instantiate VelocityEngine objects along with various POJOs that Spring assembles. These POJOs are sort of like macros and/or scripting support, have been configured with setter-injection, and are exposed to templates using a VelocityContext object. My problem is that I intend to reuse these VelocityEngine and POJOs across multiple requests, so I do not want to allow template authors to call setter methods and effectively reconfigure the POJOs. Is there an easy way to either have Velocity prevent certain method calls on context objects, or otherwise a way to make these POJOs immutable? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Immutable pojos as context objects
Mike Kienenberger wrote: Well, the easy answer to this part of the question is to implement a custom Uberspect. http://jakarta.apache.org/velocity/api/org/apache/velocity/util/introspection/Uberspect.html There's examples of this on the wiki: http://wiki.apache.org/jakarta-velocity/MultiUberspect http://wiki.apache.org/jakarta-velocity/LuceneDocumentUberspect Thanks, I'll take a look. or otherwise a way to make these POJOs immutable? Outside of the scope of velocity, but really the heart of the problem even with a custom Uberspect. At some point you either need to enumerate all objects you want to be immutable (or mutable), or you need to only stick immutable objects into the context. Personally, I think the second method is easier and safer. Why don't you stick your POJOs into the template as a wrapper object (delegate), with only the getter methods exposed? Yes, I was looking for something more like this. I know this is tangential to Velocity, but figured it might be something others had faced when trying to restrict what template authors could do. I was looking to extend VelocityContext to add a putImmutable(key, object) method. This would create an AOP-style proxy object that will fail on any set method but otherwise just hand calls to the underlying POJO. Probably something CGLIB could do for me. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
