Singleton or Engine?

[Tim Colson <tc...@cisco.com>]

To answer a question posed by Affan, Geir wrote:
> There's a subtlety and that is if you use the singleton
>     Velocity.init()
> or the engine
>    VelocityEngine ve = new VelocityEngine()
> in which case the former is the singleton, and things stay 
> around until the classloader is GC-ed (which may be never 
> depending...), and the latter is an instance, in which 
> once no on is using the ve, 
> it will be a candidate for GC.
> 
> I'd use the separate instance if you can.  Much cleaner.

I've always been curious about this... would you mind going a little
deeper as to why the ve is 'cleaner' than Velocity.init()? 

Also, when is it a good example of using each? 

I'm trying to decide pro/con which would be better to use if a developer
had created a class with several UI methods, each of which uses Velocity
to render small bits of data? (I just came across one of these, and yes,
I am certain it could be architected in an entirely different way...but
it serves well to illustrate)

This is just a stripped proto of the beast for illustration.

class RenderUtil {

public RenderUtil () {  
 Velocity.init() // singleton
}

public String renderTable(TableObject o) {
  VelocityContext context = new VelocityContext();    
  context.put("o",o.getItemValues());
  return runVel("table.vm", context);
}

public String renderList(ListObject o) {
  VelocityContext context = new VelocityContext();    
  context.put("list",o.getListValues());
  return runVel("list.vm", context);
}

public String runVel(templateName, context) {
  StringWriter sw = new StringWriter();
  Template template = Velocity.getTemplate(templateName);
  template.merge( context, sw );
  return sw.toString();
}
}

PRO
---
Sounds like the templates would be cached for all instances of
RenderUtil, for the life of the app.


CON
---
Hmm... same as the PRO, that cacheing could be unwanted

Thanks,
Timo


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

Re: Singleton or Engine?

[Geir Magnusson Jr <ge...@4quarters.com>]

On Feb 27, 2004, at 10:41 AM, Tim Colson wrote:

>
> To answer a question posed by Affan, Geir wrote:
>> There's a subtlety and that is if you use the singleton
>>     Velocity.init()
>> or the engine
>>    VelocityEngine ve = new VelocityEngine()
>> in which case the former is the singleton, and things stay
>> around until the classloader is GC-ed (which may be never
>> depending...), and the latter is an instance, in which
>> once no on is using the ve,
>> it will be a candidate for GC.
>>
>> I'd use the separate instance if you can.  Much cleaner.
>
> I've always been curious about this... would you mind going a little
> deeper as to why the ve is 'cleaner' than Velocity.init()?

Because then you can create multiple instances (if you need to have 
differently configured engines) or just cycle the engine if you want to 
change the configuration in a long running server program or something.

>
> Also, when is it a good example of using each?

I can't think of a good reason for using the singleton.  I tried to 
avoid singletons in general at all costs if I can.

>
> I'm trying to decide pro/con which would be better to use if a 
> developer
> had created a class with several UI methods, each of which uses 
> Velocity
> to render small bits of data? (I just came across one of these, and 
> yes,
> I am certain it could be architected in an entirely different way...but
> it serves well to illustrate)
>
> This is just a stripped proto of the beast for illustration.
>
> class RenderUtil {
>
> public RenderUtil () {
>  Velocity.init() // singleton
> }

[SNIP]

How about

  public RenderUtil(VelocitEngine ve) {
    this.ve = ve;
}

and

public String runVel(templateName, context) {
   StringWriter sw = new StringWriter();
   Template template = ve.getTemplate(templateName);
   template.merge( context, sw );
   return sw.toString();

> PRO
> ---
> Sounds like the templates would be cached for all instances of
> RenderUtil, for the life of the app.
>
>
> CON
> ---
> Hmm... same as the PRO, that cacheing could be unwanted
>

Only problem w/ the above is that you, the container, can't change the 
VE in the RenderUtil if want to.

To solve this you could either add a setVelocityEngine() method onto 
RenderUtil (or better have a class that RenderUtil just extends that 
deals w/ all the Vel stuff...) or encapuslate the VE in a container 
that you hand to the RenderUtil CTOR:

class VelContainer {

   VelocityEngine ve;

   VelocityEngine getVE() {
      return ve;
   }


public RenderUtil(VelContainer vc)
    this.myVelContiner = vc;
}

and then don't keep a reference to the VE.  Ask the VelContainer for 
it, and then you can change the VE whenever you want, and RenderUtil 
won't know the difference...

geir


> Thanks,
> Timo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geir@4quarters.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org