|
From: William G. T. Jr. <wg...@ru...> - 2004-08-17 23:34:10
|
Nick Lothian wrote: [snip] > > 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. Yes, of course a ServletContext is available to dispatched JSP views, and data stored in either context is available to each, as per the spec anyway. My point was that Portlet code is meant to deal with PortletAPIs not ServletAPIs and visa versa. However, as you pointed out that doesn't neccesily stop us from having PortletApplicationContext extend WebApplicationContext and be available where the RequestContext and the rest of the View package expect it. Thoughts? Bill > > 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 > |