Jason van Zyl wrote:
>
> 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.
I don't think that assumption has to be there. That 'polymorphism', in
that
$object.foo
can be rendered from a Map or *any* class that looks like
class MyClass
{
public String getFoo();
public String get( String );
}
w/o inheritance worries is a really great feature.
> 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 think that this is solvable. If you generate code like :
try
{
reference.getName();
}
catch( <whatever>Exception e )
{
introspect...
}
then you can make your assumption but also let Velocity be flexible.
> 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.
I'm not sure that is a valid assumption to make, because bean behavior
makes no assumptions about class hierarchy - simply a set of patterns
for getters/setters.
This is a huge 'paradigm shift' for Velocity - going from bean behavior
support to worrying about implements / extends...
> 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.
Why? A Sheep has wool and a moose slobbers. (Dunno... sorry, moose
fans..)
Even if they have the same base class, it says nothing about what kind
of additional methods the derived classes add.
So you could always do, in velocity :
<td> Wool : </td><td> #if($creature.wool) $creature.wool #else N/A
#end </td>
<td> Slobber : </td><td> #if($creature.slobber) $creature.slobber
#else N/A #end </td>
Right? So it seems reasonable that a designer can have domain knowledge
about the data he/she has to handle - suppose you were making a form for
shipping your creature - you might want to know if you need to bring a
vacuum or a mop...
> 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.
People would beat us with a stick. You wouldn't only need a base class
then, you would need a uberclass adapter to make sure that a Sheep can
slobber. And then theres the maintenance problem of having to recompile
your adapter code whenever you add a new 'behavior'.
The current behavior means that the model can be dynamic and only the
designer has to deal with it. I use Maps all the time for this - when I
have a new 'property', it's a new key in the map :
$creature.wool
$creature.slobber
$creature.moo
Easy in the template.
> 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 use it as I said above : it means I generally don't have to hardcode
my data model - I have the 'data API', the contract between the model
and the designer, and then I am free to be as flexible [lazy] as I want
to be, and the designer never has to know. If I use a Map, great. If I
use a formal class with actual getter methods, cool too.. no one is the
wiser in template land...
> 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 think this is an assumption that may go away with a little
investigation.
geir
> 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.
>
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
