Re: Frustrated by template location issues

Marc,

This is a good analysis.

What do other people think of refactoring the Broker?

Lane

Marc Palmer wrote:

>
> 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
> _______________________________________________
> Webmacro-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/webmacro-user
>

-- 
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868



-------------------------------------------------------
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