Menu
▾
▴
springframework-developer
|
From: Nick L. <nl...@es...> - 2004-08-11 23:49:54
|
> > Nick Lothian wrote: > > Should I be able to use the spring tag library within a Portlet? > > It should, but as you have found out it does not at the moment. > > The intent is to have all the WebMVC View technology available in > PortletMVC. However, much of the View technology is dependent on > specifics of the Servlet API. To get around this we wrote a "bridge" > Servlet which PortletMVC delegates to for rendereing. This > works ok for > simple JSTL views and allows one to use the Portlet taglib. > > The problem now is that <spring:bind ...> is dependendant upon > WebApplicationContext...which is not available in PortletMVC, > so we'll > have to figure out a way to also "bridge" the taglib. > Essentially if we > are running in PortletMVC we need the tablibs to look for > PortletApplicationContext instead of WebApplicationContext or come up > with an abstraction for both and refactor the tablib. > > later. > Bill > > Why can't PortletApplicationContext inherit from WebApplicationContext? Logically it would make sense - the portlet specification leaverages the servlet spec, even if there are no interfaces shared between the specifications. Nick |
|
From: Nick L. <nl...@es...> - 2004-08-12 23:14:20
|
> > > > 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 |
|
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 > |
|
From: Nick L. <nl...@es...> - 2004-08-18 06:06:18
|
> > 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 think it makes a lot of sense to do that. In the JSP pages included in a Portlet you can make use of JSP/Servlet features - I think Spring should do the same thing. Nick |
|
From: William G. T. Jr. <wg...@ru...> - 2004-08-12 22:22:37
|
Nick Lothian wrote: >>Nick Lothian wrote: >> >>>Should I be able to use the spring tag library within a Portlet? >> >>It should, but as you have found out it does not at the moment. >> >>The intent is to have all the WebMVC View technology available in >>PortletMVC. However, much of the View technology is dependent on >>specifics of the Servlet API. To get around this we wrote a "bridge" >>Servlet which PortletMVC delegates to for rendereing. This >>works ok for >>simple JSTL views and allows one to use the Portlet taglib. >> >>The problem now is that <spring:bind ...> is dependendant upon >>WebApplicationContext...which is not available in PortletMVC, >>so we'll >>have to figure out a way to also "bridge" the taglib. >>Essentially if we >>are running in PortletMVC we need the tablibs to look for >>PortletApplicationContext instead of WebApplicationContext or come up >>with an abstraction for both and refactor the tablib. >> >>later. >>Bill >> >> > > > 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/JSR168/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 |
