Re: More, this time - Spring plus WM?

We actually had two implementations of a WM/Spring integration done last 
September.  I believe Sebastian's is available in our CVS.  I've 
included his message below.

Keats

Marc Palmer wrote:

>
> Guys,
>
> Is anybody out there using Spring with WebMacro? Any likes/dislikes?
>
> It struck me that for a start we could do something really nice using 
> Spring's IoC for starters, i.e. a SpringContextAutoLoader that would 
> allow us to bootstrap beans (be they simple helpers, factories, or 
> dare I say EJBs) that go into the context.
>
> This should be a relatively simple task. I'll look into it a bit more. 
> I'm not saying make Spring a required dependency of WM, but having a 
> good optional IoC XML configuration mechanism would be a real boon to 
> WM usage I think.
>
> I'm seriously considering using it to replace my somewhat clumsy 
> plugin/action/helper configuration mechanism in Ignition.
>
> Cheers
>
>
Hi Hai, Sebastian,

Couple of observations from experience.

If you have read the new book, "Effective (or is it) Better Java", you 
will note that the author stresses the importance of decoupling 
dependencies. Therefore, I do not like either of the solutions below 
because you are subclassing WMServlet and WMBroker. What if they have 
side effects? Change? Are inadequate? WMBroker has a lot of 
implementation internals which could break a subclass.

 From experience, both WMServlet and WMBroker have issues. Rather, I 
would like to see a POJO whose containment of a WebMacro context and, 
consequently, a broker, plus a number of convenience methods, make it 
the place to create the bridge object between Spring and WM. Let's call 
it WMSpring. (See o.w.u.WMEval for a class which could be remade easily 
into WMSpring). Thus, in WMSpring, you provide the bridges to both 
Spring and WebMacro which can be used in both a Servlet context and a 
non-servlet context. There are convenience initializers for both kinds 
of environments and for web context tools as needed.

see: http://www.webmacro.org/api/org/webmacro/util/WMEval.html
(the docs are a bit out of date).

I do not want to be tied to subclassing WMServlet. Generally, creation 
of an adapter is accomplished thru composition by a POJO.

kindest,

Lane

Hai-Chen Tu wrote:

> Hi,
>     I exchanged several email with Sebastian on WebMacro-Spring 
> integration
>     issues and here is a summary of our discussion. It happened that
>     we have different approaches to implement the integration and I will
>     first describe the key parts of our approaches and then present
>     some issues I have. You are all welcome to give your views and 
> suggestions.
>     Hopefully at the end of discussion we will have a version of 
> integration
>     that everyone is    happy to use.
>
>     Sebastian's approach:
>         * a CommonsLog class that implements WebMacro's Log interface
>             using apache's common log API.
>         * a SpringBroker class that extends WebMacro's Broker. It uses
>             CommonsLog as the logger and Spring's ResourceLoader
>             as the resource loader.
>         * The WebMacro engine is created using SpringBroker.
>         * rendering output is done through
>             template.write(response.getOutputStream(), context);
>
>     My approach:
>         * ServletBroker: under the Spring MVC framework, I couldn't 
> find any API
>             to access the DispatchServletcan to create a ServletBroker.
>             So I wrote a utility that creates a 
> Servlet20Broker/Servlet22Broker
>             using the ServletContext retrieved from the Spring 
> application context.
>             (There is probably a way to use Sebastian's CommonsLog as
>              the logger for this ServletBroker but I don't know how to 
> do it.)
>         * The WebMacro engine is based on WMServlet (which is probably
>             a mistake but please read on). Since there is
>             no servlet available during init time, I wrap WMServlet
>             in a thin subclass and override its initWebMacro() and use
>                 new WM(broker created from the above mechanism)   
>             to create a WM.
>         * rendering output is done through
>             WMServlet.execute(Template, WebContext)
>         * I also recycle WebContext instances
>
>     The reasons I want to use WMServlet are because
>         1. I can use error.wm:
>         2. I can use #param to set TEMPLATE_OUTPUT_ENCODING and
>             TEMPLATE_LOCALE
>         3. I can use ContextTools, e.g., $CGI.
>
>     About error.wm, I am not quite sure if it is important to use it.
>     I did, however, use it in my applications.
>
>     Sebastian thinks that there is no need to use WMServlet and
>     one can still access ContextTools without WMServlet. I think he is
>     correct but I think a ServletBroker is still needed to be able to 
> create
>     CGI_Impersonator, and probably some other ContextTools. If this
>     is the case, we may need to consolidate his SpringBroker and
>     ServletBroker.
>
>     On encoding/local setting, if we don't use WMServlet, then we 
> probably
>     want to allow developers to specify template encoding/locale
>     through Spring's configuration file per WebMacroView  bean (each 
> template
>     has a one-one correspondence with a view), which is the mechanism
>     Spring-Velocity integration uses.  
> Sebastian,
>     Could you describe the difference between Spring ResourcLoader
>     and default resource loading used by Servlet20Broker/Servlet22Broker?
>        Hai-Chen Tu
>    





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click