velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: velocimarco.library property and StringResourceLoader
Date Thu, 08 Jan 2009 15:18:02 GMT
Raymond Auge wrote:
Thanks, Ray.  Further comments and questions inline
> Hey Steve,
>
> I just re-purposed our entire Velocity usage to use StringResourceLoader
> where before we were calling "evaluate()" ALL THE TIME... it was killer
> on resources as you might imagine.
>   
Hmm.  I haven't noticed resource problems yet.  I'm not calling 
evaluate() now; I am using the VelocityEngine.mergeTemplate() approach.  
Does mergeTemplate() have a greater or lesser resource-consumption 
footprint than evaluate()?
> So, this is the core code, it's very simple. So, we have a wrapper class
> that is a Singleton that setups up a non-singleton VelocityEngine
> instance 
Exactly my setup.

> (so that other apps can use their own version, all good). This
> wrapper handles all the setup and configuration of Velocity. It also
> provides these methods:
>
>
> public boolean mergeTemplate(
> 		String templateId, VelocityContext velocityContext, Writer writer)
> 	throws SystemException, IOException {
>
> 	return mergeTemplate(templateId, null, velocityContext, writer);
> }
>
> public boolean mergeTemplate(
> 		String templateId, String template, VelocityContext velocityContext,
> 		Writer writer)
> 	throws SystemException, IOException {
>
> 	try {
>   
what's Validator()?
> 		if (Validator.isNotNull(template) && !resourceExists(templateId)) {
> 			StringResourceLoader.getRepository().putStringResource(
> 				templateId, template);
>
> 			if (_log.isDebugEnabled()) {
> 				_log.debug(
> 					"Added " + templateId + " to the Velocity repository");
> 			}
> 		}
>
> 		VelocityContextImpl velocityContextImpl =
> 			(VelocityContextImpl)velocityContext;
>
> 		return _velocityEngine.mergeTemplate(
> 			templateId, StringPool.UTF8,
> 			velocityContextImpl.getWrappedVelocityContext(), writer);
> 	}
> 	catch (IOException ioe) {
> 		throw ioe;
> 	}
> 	catch (Exception e) {
> 		throw new SystemException(e);
> 	}
> }
>
>
> So, as you can see, where we would have normally passed a string to
> velocity's evaluate method, now we call
>
>
> VelocityEngineUtil.mergeTemplate(scriptId, script, velocityContext, output);
>
>
> and if the script is not in the repo, then add it. If it already got
> added to the repo, then it will be found by name (scriptId) and
> retrieved as a ready Template, which means you saved all the AST
> re-parsing overhead.
>
>
>
> I do have a question of my own. How many strings in the repository is
> too many? Or an overall size. Can they have a time-to-live?
>
>
> Ray
>
>
>   
so I guess my question now boils down to what the tradeoffs are in 
resource consumption between evaluate() and mergeTemplate().  I was 
looking at StringResourceLoader more as a tool of development 
convenience than as a tool of resource maximization, but it looks like 
that may not be not its primary purpose.



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


Mime
View raw message