Very interesting stuff Jason.
However...
> 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.
Maybe it is not normal, but I have a lot of that in my framework. And
I can still thing of many other cases where I would use this.
However, it shouldn't be very hard to have 2 types of templates, or 2 types
of variables (as you mention for XMLC).
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jason van Zyl
> Sent: Tuesday, April 17, 2001 07:32
>
>
> 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.
> ..............
>
> 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]
