|
From: Rainer S. <Rai...@ab...> - 2004-04-22 13:26:12
|
I followed the portlet thread a few days ago. I'm just starting to learn about portlet development and as a Spring user I would like to use a Portlet / Spring integration from the beginning. Are there any examples on how to compbine portlets and spring? What's the state of the FrameworkPortlet development? Rainer |
|
From: William G. T. Jr. <wg...@ru...> - 2004-04-27 01:16:23
|
We just upgraded our uPortal implementation to uP2.3 which supports the portlet api via pluto so we're ready to start experimenting with Spring support. I'd like to start a org.springframework.web.portlet package modeled after org.springframework.web.servlet. Has anyone started on this yet? Bill Rainer Schmitz wrote: > I followed the portlet thread a few days ago. I'm just starting to learn > about portlet development and as a Spring user I would like to use a > Portlet / Spring integration from the beginning. > > Are there any examples on how to compbine portlets and spring? What's > the state of the FrameworkPortlet development? > > Rainer > > |
|
From: William G. T. Jr. <wg...@ru...> - 2004-04-27 04:48:24
|
OK, I've almost got something we can play with... GenericPortlet -> PortletBean -> FrameworkPortlet -> DispatcherPortlet* Plus various supporting objects which are mostly a mirror of ...web.context and web.context.support. The Portlet API varies enough to have to change most of these objects in subtle ways. Mostly it was a cut&paste/replace Servlet with Portlet kind of a job. I had to deviate from that approach when the Portlet API didn't have the same methods available, getURI() for instance, or where the calling semantics are different, like processAction/render vs doGet/doPost. * I'm just about to tackle DispatcherPortlet. It will differ from DispatcherServlet in that it can have different HandlerAdaptors configured per PortletMode (view, edit, help,...). Most likely candidate for HandlerMappings keys are Request parameters and Session attributes. The DispatcherPortlet also reflects the Portlet two step call with abstract methods doRenderService() and doActionService() instead of just doService(). Finally, the Porlet API assumes things like multipart request and locale selection will be handled by the portal application so multipartResolver and localeResolver are probably out. I am hoping to have something working in a few days. later. Bill William G. Thompson, Jr. wrote: > We just upgraded our uPortal implementation to uP2.3 which supports the > portlet api via pluto so we're ready to start experimenting with Spring > support. I'd like to start a org.springframework.web.portlet package > modeled after org.springframework.web.servlet. Has anyone started on > this yet? > > Bill > > > Rainer Schmitz wrote: > >> I followed the portlet thread a few days ago. I'm just starting to >> learn about portlet development and as a Spring user I would like to >> use a Portlet / Spring integration from the beginning. >> >> Are there any examples on how to compbine portlets and spring? What's >> the state of the FrameworkPortlet development? >> >> Rainer >> >> > |
|
From: William G. T. Jr. <wg...@ru...> - 2004-04-28 04:30:04
|
Well, we are up to about 24 classes from org.springframework.web.servlet ported to org.springframework.web.portlet. DispatchPortlet is getting closer. One question is what to do about Action requests which are not expected to generate any View. Feels like I need another method on HandlerAdapter. // Render Requests ModelAndView handle(RenderRequest request, RenderResponse response); // Action Request void handle(ActionRequest request, ActionResponse response); maybe we'll be rendering views tomorrow... later. Bill William G. Thompson, Jr. wrote: > OK, I've almost got something we can play with... > > GenericPortlet -> PortletBean -> FrameworkPortlet -> DispatcherPortlet* > Plus various supporting objects which are mostly a mirror of > ...web.context and web.context.support. The Portlet API varies enough > to have to change most of these objects in subtle ways. Mostly it was a > cut&paste/replace Servlet with Portlet kind of a job. I had to deviate > from that approach when the Portlet API didn't have the same methods > available, getURI() for instance, or where the calling semantics are > different, like processAction/render vs doGet/doPost. > > * I'm just about to tackle DispatcherPortlet. It will differ from > DispatcherServlet in that it can have different HandlerAdaptors > configured per PortletMode (view, edit, help,...). Most likely > candidate for HandlerMappings keys are Request parameters and Session > attributes. > > The DispatcherPortlet also reflects the Portlet two step call with > abstract methods doRenderService() and doActionService() instead of just > doService(). Finally, the Porlet API assumes things like multipart > request and locale selection will be handled by the portal application > so multipartResolver and localeResolver are probably out. > > I am hoping to have something working in a few days. > > later. > Bill > > > > William G. Thompson, Jr. wrote: > >> We just upgraded our uPortal implementation to uP2.3 which supports >> the portlet api via pluto so we're ready to start experimenting with >> Spring support. I'd like to start a org.springframework.web.portlet >> package modeled after org.springframework.web.servlet. Has anyone >> started on this yet? >> >> Bill >> >> >> Rainer Schmitz wrote: >> >>> I followed the portlet thread a few days ago. I'm just starting to >>> learn about portlet development and as a Spring user I would like to >>> use a Portlet / Spring integration from the beginning. >>> >>> Are there any examples on how to compbine portlets and spring? What's >>> the state of the FrameworkPortlet development? >>> >>> Rainer >>> >>> >> > |