RE: [Springframework-developer] Portlets and spring tag library

[Nick L. <nl...@es...>]

> > 
> > Why can't PortletApplicationContext inherit from 
> WebApplicationContext?
> 
> Maybe it can.  Though I do not believe the ServletContext is 
> meant to be 
> directly available to Portlets the way the 
> PortletApplicationContext and 
> the PortletContext are and visa versa.
> 
> > 
> > Logically it would make sense - the portlet specification 
> leaverages the
> > servlet spec, even if there are no interfaces shared between the
> > specifications.
> 
> While the portlet spec does leverage the servlet container, the APIs 
> differ enough to make it difficult to support to Spring 
> WebMVC directly. 
>   Which is why we currently have the View Servlet bridge.
> 
> The main goal is to provide MVC framework similar to Spring 
> WebMVC for 
> the Portlet API.  Portlets can be thought of as Servlets with 
> additional 
> lifecycle and constraints.  They are essentially web 
> applications with 
> defined "modes" and are restricted to outputting markup that can be 
> embedded in a final document.  Portlets benefit from 
> PortletMVC the same 
> way Servlets benefit from WebMVC and a Spring layered architecture.
> 
> The starting pointing was to create a DispatcherPortlet, the 
> analog of 
> DispatcherServlet.  This initially led to the creation of many mirror 
> objects from o.s.web.servlet.*.  I simply ported many objects to the 
> web.portlet.* package with the ServletAPI dependencies 
> replaced with the 
> PortletAPI.  This madness would have led to duplicating the 
> View support 
> as well had it not been for Juergen's design proposal:
> http://opensource.atlassian.com/confluence/spring/display/JSR1
68/SpringPortlet+module+design+discussion

To get the spring tag libs to work in this model it looks like we need 
to make them aware of and compatible with the View bridge, or provide 
PortletMVC specific implementations.  Thoughts?

later.
Bill


Yes, I've read
<http://opensource.atlassian.com/confluence/spring/display/JSR168/SpringPort
let+module+design+discussion>. 

I thought the point of the bridge design is to "reuse the existing
Servlet-based classes themselves as far as possible" and "reuse the entire
view support of the web.servlet.view package, working with
HttpServletRequest/Response at the View level" and I guess that's what made
me think that the tag libs would be supported.

I think that the ServletContext is supposed to be available to JSP views
used from a Portlet. The spec says nothing about restricting it, and in any
case, without a ServletContext JSP's are pretty useless.

I'm quite familiar with the problems the duel Portlet* & Servlet* heirachy
gives. That's why I quite like the bridge solution Spring uses - it seems a
neat way around it.

Nick