Thanks for the comments, Jon. 

> The scary idea here is that foo could make database connections
> or get data
> via XML-RPC/SOAP/however you want. Imagine your precompiler querying a
> database to find out compile time information! Twisted indeed.

Being able to access Java objects from my templates was the main motivation for using Velocity in the first place.  An OR mapping tool that I've written currently uses Velocity and a subclass of Texen to parse db metadata and generate all of my db classes.

In fact, I was assuming that one could call Class.forName directly from VTL, which is why I had asked, 'what more could you want?', but apparently VTL doesn't support Class.forName directly (thought there is a cheat).

So here are some questions in my mind for which you might have some input, based on the example you gave.  Don't feel compelled to respond though; just getting these thoughts down helps me out.

> <vppjavac>
>     <context key="foo" object="org.mypath.Foo" />
> </vppjavac>

1.  I understand the example you gave was probably made pretty well off the cuff, but even so, would not be at all difficult to implement.  However, I'm not sure how generally useful such an object would be that is instantiated without any context.  For example, if Foo were to try to connect to a db, how could it be made to know which db to go after?  Clearly it could be hard-code with configuration information, but that seems silly given that Ant is there to provide configuration information for the whole build process.

2. What would the lifecycle of Foo be?  Would one object be created for the entire executoin of the task, or would an instance be created for each template processed?  (Currently, a VelocityEngine and VelocityContext is created for each VPPFilter.  VPPFilter clones share the same VelocityEngine and VelocityContext.  VPP and VPPJavac embed a single instance of VPPFilter each.  It may be desireable that a separate context is needed for each evaluation so no garbage is left in the context.)

The second question implies that their might be the need also to have communication between VPP and whatever objects are instantiated.  For example, VPP could pass the Velocity context to the object, then give the object a chance to init, reset itself between templates, and cleanup when it's all done.  Such an object would be a kind of mediator between VPPFilter and the templates. 

For example:

public interface VPPFilterMediator {

    /**
    * Called after instantation
    */
    public void setVelocityContext(VelocityContext velocityContext);

    /**
    * Called once, after setVelocityContext() to allow for initialization
    */
    public void init();

    /**
    * Called at the start of every template evaluation.
    */
    public void start();

    /**
    * Called at the end of every template evaluation
    */
    public void stop();

    /**
    * Called when there are no more templates to evaluate
    */
    public void destroy();
}

Of course, the object could be dumb with respect to the build context and use some other method entirely, like read a property file or access a fixed name server for connections.

Any thoughts would be appreciated.

didge

PS I'll be moving the license to BSD shortly.

> -----Original Message-----
> From: Jon Scott Stevens [mailto:jon@latchkey.com]
> Sent: Friday, December 20, 2002 6:16 PM
> To: didge@foundrylogic.com; general@jakarta.apache.org
> Subject: Re: New Preprocessing tool
>
>
> on 2002/12/20 6:05 PM, "didge" <didge@foundrylogic.com> wrote:
>
> > After reading up regarding licensing a bit more, I'm going to consider
> > switching to an ASF or BSD license.
>
> Good idea.
>
> >  Shouldn't matter much right now because
> > I don't think anyone is planning to redistribute this :)
>
> You never know...I could actually use something like this for Scarab's
> build. Right now, I'm just using the <replace> tag for some minor
> precompiling that I need to do...but this would be much more fun.
>
> This is a great way to entirely get rid of logging statements from the
> source code at compile time...
>
> #if ($logging)
>   log.debug("Foo");
> #end
>
> > I'm not sure what else you would want or even could put in the context.
>
> Exactly! The key is to be able to make it dynamic. Allow people to specify
> objects which they can put into the context via the build.xml. It
> will then
> instantiate the object with Class.forName() and make it available in the
> context.
>
> Something like:
>
> <vppjavac>
>     <context key="foo" object="org.mypath.Foo" />
> </vppjavac>
>
> The scary idea here is that foo could make database connections
> or get data
> via XML-RPC/SOAP/however you want. Imagine your precompiler querying a
> database to find out compile time information! Twisted indeed.
>
> =)
>
> -jon
>
> --
> StudioZ.tv /\ Bar/Nightclub/Entertainment
> 314 11th Street @ Folsom /\ San Francisco
>         http://studioz.tv/
>
>