Ben Alex wrote:
> Hi Bill
>
>
>>Rutgers is very interested in Spring support for the Portlet
>>API in the form of a PortletDispatcher as it were. We run
>>the uPortal[1] platform and the latest release embeds Pluto.
>>We are just now embarking on dev cycle for new porlets that
>>takes us thru september, if possible these new portlets would
>>live behind a Spring PortletDispatcher.
>>
>>We have had some preliminary dicussions with Alef about what
>>it might look like, and should be in a better positition to
>>try out some ideas/code in a few weeks.
>
>
> I took a look at uPortal but wondered how hard it would be to get Spring MVC
> capabilities living within a portlet window. Have you actually done anything
> like this as yet, or are your Spring applications essentially "traditional"
> (dedicated JSP/VM etc)?
>
So far all of our Spring apps are "traditional"; leveraging the full
compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction,
ApplicationContext, declaritive transaction management, AOP, etc.) and
living in a dedicated Servlet context.
We have used Spring DAO/JDBC support for a few simple Channels
(Portlets), but that is the extent of it.
We are extremely pleased with the Spring development model and would
like to bring our portal project in line.
I don't think it should be too hard to bring SerlvetDispatcher behavior
to the Portlet API. The big difference is that Portlets participated in
a two step call (ActionRequest/Response and RenderRequest/Response) and
also have additional lifecycle events, PortletMode (View, Edit,
Help,...) and WindowMode (min, max, normal, etc.) that impact behavior
of the service.
later.
Bill
|
