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