Re: [WebMacro-user] Frustrated by template location issues

[Lane S. <la...@op...>]

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 (ma...@an...)
> 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
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-user
>

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