Dave Bryson wrote:
>
> Hey guys,
>
> Maybe i'm spinning my wheels on the wrong problem.
What's the problem you are trying to solve?
> If we want to be able to jar the templates why not just compile them?
> Then we get the extra performance as well.
>
> Multi-path is not an issues then it's handled by the classloader.
With the ClasspathResourceLoader, its not an issue - you can multipath
to your hearts content (and you can do it with JarResourceLoader and
FileResourceLoader now, right?)
> This would be nice in Turbine - compile the templates and Turbine code
> all into one jar - could be an extra build step in the TDK.
You can jar the code and templates and it will be fine now - the
templates don't have to be compiled.
> How hard would it be to compile the templates?
It wouldn't be hard - as jon said, you could just store a serialized
AST.
I just am not sure I understand the gain - the parsing process is
relatively quick, and since Vel caches the ASTs, it only happens once.
So the only upside I see is that the first use of the template doesn't
need to be parsed, because the organizational advantages is a wash - you
can jar you code and templates together now and use the
ClasspathResourceLoader or the JarResourceLoader
The downside would be the added complexity of configuration and loading
of two types of streams, plus the horrible situation when you have
deployed templates as serialized ASTs and we change something internally
in Velocity - you would have to redeploy all your templates.
geir
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
