velocity-user@jakarta.apache.org
[Top] [All Lists]

Re: Re[2]: Custom Resource Loader

Subject: Re: Re[2]: Custom Resource Loader
From: "Will Glass-Husain"
Date: Tue, 14 Dec 2004 09:25:04 -0800
Inversion of Control. Check out Spring (www.springframework.org) to see a framework following this approach.

I'm going to probably botch this definition up, but the basic idea is that all configuration is done from the container application via getters and setters. This means the container (e.g. the calling code) is in control rather than the library. In general, this means that Velocity should accept both string properties for configuration and also (when appropriate) actual instances of resource loaders, loggers, etc. In some cases this is academic. In others (such as the DataSourceResourceLoader) this is more important. In that case to use IOC the container needs to pass in a live dataSource (created by the container) rather than just a username/password/URL.

See this blog entry for how Matt Raible used this patch to adapt Velocity to support IOC with the DataSourceResourceLoader.
http://jroller.com/page/raible?anchor=loading_velocity_templates_from_the

WILL

----- Original Message ----- From: "Shinobu Kawai" <shinobu.kawai@xxxxxxxxx>
To: "Velocity Users List" <velocity-user@xxxxxxxxxxxxxxxxxx>
Sent: Tuesday, December 14, 2004 8:20 AM
Subject: Re: Re[2]: Custom Resource Loader


Hi Stan,

Still, I think, it would be a very good idea to slightly redesign
VelocityEngine class for better support of IoC setup.

## BTW, what does "IoC" stand for?

You can check out Hibernate to see how they designed it - you
can configure it in both programmatic and declarative ways - and that
rocks! :)

Imagine, how cool it would be to be able to write such code:
===
 velocityEngine.setResourceLoader(customResourceLoader);
===

Or, if Velocity team wants to provide support for multiple resource
loaders (I guess this is not so common case though), it could be like
this:
===
 velocityEngine.addResourceLoader(customResourceLoader);
===

customResourceLoader is a programmatically pre-configured ResourceLoader here.

If the above code could be possible, I'd be happy to donate
LocaleResourceLoader class for Velocity team and it would greatly
enrich Velocity product, since i18n is a very common demand.

What do you think about that? :)

I think it kind of goes against the configure once and only once stated here:

http://jakarta.apache.org/velocity/developer-guide.html#The%20Velocity%20Helper%20Class
You could get concurrent issues, too.
Having said that, a mutable ResourceLoader might fulfill your needs.
(But currently, you can't get the resource loaders from the engine.)

BTW, Velocity supports multiple resource loaders already.  (Not in a
programmatic way, though.)

http://jakarta.apache.org/velocity/developer-guide.html#Resource%20Loaders
<excerpt>
#
# specify three resource loaders to use
#
resource.loader = file, class, jar
</excerpt>

Best regards,
-- Shinobu Kawai

--
Shinobu Kawai <shinobu.kawai@xxxxxxxxx>

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: velocity-user-help@xxxxxxxxxxxxxxxxxx



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: velocity-user-help@xxxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>