Frustrated by template location issues

Marc Palmer <[email protected]> Mon, 12 Dec 2005 16:21:36 +0000
Newsgroups gmane.comp.java.webmacro.user
Message-ID <[email protected]>
Hi all,

I'm going round the houses on this again with WM. I even looked at  
Velocity to get me out of this but it looks like they copied WM so  
closely they took the bad (in my opinion) config mechanisms!

However it's not all WebMacro's fault :)

What I'm trying to do is slightly unusual - although I've been down  
this road before.

For me, it is important to be able to configure new instances of WM  
at runtime. The core issue here is being able to set a specific  
template location per WM instance I create, and there will be  
multiple instances each with different paths.

Issue 1: This requires you to manually create Properties objects with  
the correct settings and pass them to the WM constructor. I've said  
it before and I'll say it again - WebMacro.addTemplateProvider 
( myProvider) would really be very nice. Sadly the Broker complicates  
all this.

Issue 2: I'm interfacing with Spring, but this problem would likely  
exist with any bean container. I'm creating a Spring MVC view  
instance that creates WebMacroView objects that need a reference to a  
WebMacro instance. This is easy, until you realise you want different  
WM instances with different paths, and you only know the template  
paths after the view resolver (which creates the WebMacroView  
instances) has been created.

The latter is a general Spring/container problem. If Spring's  
ViewResolver supported a mechanism for setting paths used by the view  
later to locate resources, this would be much easier to fix.

Anyway, just whining really. There is no clean solution I can see at  
the moment, and it requires specific hacking for each view technology :(

Can we -please- have bean-based config in WM 3? I will happily do  
most/all of this work if people agree it is a good idea. We'd still  
emulate the old Broker mechanisms bit IMHO (I've said it so many  
times) the Broker needs a refactor to simplify its interface and make  
it an interface not a class. Then alternative Broker implementations  
can be easily written that interface to any of the many good bean  
container systems out there.

At the very least it would be SO nice to just create a new BeanBroker 
() and call addBean( new MyProvider()) to set it up, and then call  
new WM( myBeanBroker). With that comes easy scriptability of WM config.

Cheers

~ ~ ~
Marc Palmer ([email protected])
Consultant/Analyst
AnyWare Ltd.
http://www.anyware.co.uk/



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click