Art Gillespie wrote:
>
> Has there been a lot of design work/discussion on the compiler? I've been watching
>the CVS tree for a few weeks, and I notice that the org/apache/velocity/compiler
>package hasn't moved much/any, although I see that Jason Van Zyl has put together a
>skeleton Compiler class.
>
> Further research at the mail archives (search on compiler at theaimsgroup) doesn't
>reveal much, either, so please forgive me if I'm revisiting a design/implementation
>discussion that has already taken place or treading on anyone's pet compiler project
>territory.
>
> Is the idea to make the compiled *.vm derive from org.apache.velocity.Template and
>implement merge()? This was my idea, and I've been working on traversing the AST
>Tree and generating Jasmin (for design only... I did get the impression from the mail
>archives that on one is interested in intermediate formats in the final
>implementation : ) ).
>
> At any rate, I thought I'd check in before I spent too much time on this...
>
> Is the compiler open for discussion/development?
Sure is, I haven't gone very far with another version I have here.
I will clean up what I have and try to push it into CVS in
the next couple of days. What I have creates a Template class
in memory, something that could be placed in the cache.
The idea is to try and get rid of all reflection in an attempt
to make the rendering go as fast as possible. What I am assuming,
in order for compilation to be of any use, is that the type
represented by a reference in VTL is constant. This is not
what Velocity assumes right now.
So what I'm assuming is that in something like the following:
---
$object.Name
---
is that $object will change instances but that the $object to be
displayed will at least have the same base class. So that bytecode
can be produced that represents $object.getName(). In other words
the reflection is done once and stored, this is how Velocity originally
worked. Velocity now assumes that $object could be completely
different from one rendering to the next.
I am in agreement with Geir that this is the safest, as we discussed
this
when changes were made to support varying object types in the context
from one rendering to the next, but I don't believe this is a normal
usage
pattern. I believe that in most cases the $object type is constant, and
I would argue even further that if the type of (base class) does change
then there is some poor design somewhere.
If you had some VTL like:
---
Today's creature of the day is $creature.Name
---
and the context builder had something like
if (user.likesSheep())
context.put("creature", new Sheep())
elseif (user.likesMoose())
context.put("creature", new Moose())
and Sheep and Moose are totally disperate classes then
I would say that's a design problem.
And even if you had to pull data from disperate sources, I think
it's still possible that adapters could be used to make what
is placed into the context of a constant type. None of my applications
have any changing object type behaviour. Using the model of JSP, or XMLC
(Enhydra view mechanism) there is the notion of constant type. I haven't
done a whole lot of research into the matter but my feeling is that
the types should remain constant. Velocity protects you if this
type changes but I would be curious to see how often this actually
happens and when it does why it happens at all.
I think a compiler would work, but I don't think there is any point
in compiling something where the object type in a context can change
from one rendering to the next. I think both models would work
(constant and changing types in the context) but I'm not sure how
both would work together.
I will put what I have in CVS in a couple of days. But this should
get the ball rolling. I don't see any reason why a compiled velocity
template could not be as fast as a compiled JSP page. Maybe Jasper
and Velocity could even share the same compiler some day :-)
I am currently using the BECL (Bytecode Engineering Class Library),
which was previously called JavaClass. It's available from sourceforge,
and I've been playing with the most recent version if anyone wants
to take a look at it.
There are also many considerations to deal with given #macros, pluggable
event handlers, but we could definitely start simple and go from there.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
