RE: [Springframework-developer] Portlet and JSFs

[Kopylenko, D. <dko...@ac...>]

Juergen,

I'll look more closely into the Struts support classes tonight...

Bill, Alef, Ben,
what do you think?

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Tuesday, April 13, 2004 3:12 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


> Portlets can not access the URL that the client used to initiate the=20
> 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?

Juergen


=20

________________________________

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=20
>>the form of a PortletDispatcher as it were.  We run the uPortal[1]=20
>>platform and the latest release embeds Pluto. We are just now=20
>>embarking on dev cycle for new porlets that takes us thru september,=20
>>if possible these new portlets would live behind a Spring=20
>>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=20
>>ideas/code in a few weeks.
>
>
> I took a look at uPortal but wondered how hard it would be to get=20
> 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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer