Re: [Springframework-developer] Portlet and JSFs

[William G. T. Jr. <wg...@ru...>]

jürgen höller [werk3AT] wrote:

>>Portlets can not access the URL that the client used to initiate the request on the portal.
> 
> While that makes sense, it effectively makes me wonder whether we need a Portlet dispatcher: With Servlets, dispatching is all about flexible URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar to doGet, doPost, etc from the Servlet API.
> 
> So for typical Portlets, it's probably most important to allow for easy access to Spring facilities from those methods, rather than dispatch to some other components from a Portlet doView method. Portlet support classes similar to the ones I just added for Struts come to my mind.
> 
> This doesn't seem to be much effort at all. Am I on the wrong track here?

I haven't followed the Struts threads, but I think you are on the right 
track...we probably need:

* portlet application context  (specified in portlet config?)
* data binding
* view resolution (we'd like to use jstl)
* perhaps some portlet specific controllers

later.
Bill


> 
> Juergen
> 
> 
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Faizan Hussain
> Gesendet: Di 13.04.2004 20:38
> An: spr...@li...
> Betreff: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> 
> Please see my comments at the bottom
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> William G. Thompson, Jr.
> Sent: Friday, April 09, 2004 7:35 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
> 
> 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
> 
> Since we got into this discussion, I would like to add few more differences
> between Portlets and Serverlets.
> - Portlets generate fragments, whereas servlets generate complete documents.
> - Unlike servlets portlets are not bound directly to a URL.
> 
> According to my understanding there are few things that portlets have but
> servlets don't
> 
> - Portlets are able to perform portlet rewriting, so as to create links that
> are independent of the portal server implementation
> - portlets has two different session scopes in which to store object:
> application wide and portlet private.
> -Portlets has access to user profile information that is definitely far
> beyond the basic user and role information provided in the servlet
> specifications.
> 
> Similarly there are few things that servlets can do but portlets can not do
> that. For example
> 
> -Portlets can not alter the HTTP headers or set response encoding.
> -Portlets can not access the URL that the client used to initiate the
> request on the portal.
> 
> Later.
> 
> Faizan
>