springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Ben A. <ben...@ac...>]

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)?

Best regards
Ben

RE: [Springframework-developer] Portlet and JSFs

[<jef...@si...>]

>Would anyone be willing and have time to collaborate on this? <

yes. I start work next week for a new company where I'll be developing a
portal product. I have experience with Spring & Hibernate but have only used
Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPortal
has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not ready
yet but they report good progress.

If a Spring PortletDispatcher supported JSR-168 then it seems like it would
work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right? What
release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

Jeff W. Boring 




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ben Alex
Sent: Friday, April 09, 2004 2:33 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


Hi

> JSF and Portlet functionality don't have to be provided in 
> one and the same release. I have been looking a bit into the 
> portlet stuff and it doesn't same all that difficult.
> 
> I think I'll experiment with it during the next couple of 
> weeks. Major issue is the common supporting functionality 
> (ContextLoader, WebAppCtx,
> Databinding) between our Web stuff and our future Portlet 
> stuff (and probably also the JSF stuff). Revising the 
> supporting functionality right now (or for 1.1) is not an option imo.
> 
> I probably can't avoid having to copy-and-paste a lot of code 
> while experimenting and since that's *not* something we want 
> to have in a release, I'm afraid you're right :(.

Several people have previously mentioned portlets and JSF. We are trying to
decide whether to implement portlets in our next project, or just stick to
include files and/or something like Sitemesh, Tiles etc.

Regarding portlets, there is the Pico-based Exo project
(http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/).
Has anyone done any work on integrating portlets, JSF or projects such as
these into Spring? Would anyone be willing and have time to collaborate on
this?

Best regards
Ben



-------------------------------------------------------
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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

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

jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
> 
> 
> yes. I start work next week for a new company where I'll be developing a
> portal product. I have experience with Spring & Hibernate but have only used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPortal
> has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not ready
> yet but they report good progress.
> 
> If a Spring PortletDispatcher supported JSR-168 then it seems like it would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work 
out right for us we'll need something workable in about a month...and 
hopefully in an official Spring release by August.

later.
Bill


> 
> Jeff W. Boring 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> Hi
> 
> 
>>JSF and Portlet functionality don't have to be provided in 
>>one and the same release. I have been looking a bit into the 
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of 
>>weeks. Major issue is the common supporting functionality 
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet 
>>stuff (and probably also the JSF stuff). Revising the 
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code 
>>while experimenting and since that's *not* something we want 
>>to have in a release, I'm afraid you're right :(.
> 
> 
> Several people have previously mentioned portlets and JSF. We are trying to
> decide whether to implement portlets in our next project, or just stick to
> include files and/or something like Sitemesh, Tiles etc.
> 
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such as
> these into Spring? Would anyone be willing and have time to collaborate on
> this?
> 
> Best regards
> Ben
> 
> 

Re: [Springframework-developer] Portlet and JSFs

[Nadeem B. <na...@ea...>]

On =B2=D0, 2004-04-13 at 11:13 -0400, William G. Thompson, Jr. wrote:

> jef...@si... wrote:
> >>Would anyone be willing and have time to collaborate on this?
> >=20
> >=20
> > yes. I start work next week for a new company where I'll be developing =
a
> > portal product. I have experience with Spring & Hibernate but have only=
 used
> > Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPor=
tal
> > has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not r=
eady
> > yet but they report good progress.
> >=20

Have a look at http://www.gridsphere.org/gridsphere/gridsphere=20

> > If a Spring PortletDispatcher supported JSR-168 then it seems like it w=
ould
> > work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?
>=20
> Exactly!
>=20
>   What
> > release of Spring would the PortletDispatcher be in, 1.01 or 1.1?
>=20
> I would push for as soon as it is fully baked...for the timing to work=20
> out right for us we'll need something workable in about a month...and=20
> hopefully in an official Spring release by August.
>=20
> later.
> Bill
>=20
>=20
> >=20
> > Jeff W. Boring=20
> >=20
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On Behalf
> > Of Ben Alex
> > Sent: Friday, April 09, 2004 2:33 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >=20
> >=20
> > Hi
> >=20
> >=20
> >>JSF and Portlet functionality don't have to be provided in=20
> >>one and the same release. I have been looking a bit into the=20
> >>portlet stuff and it doesn't same all that difficult.
> >>
> >>I think I'll experiment with it during the next couple of=20
> >>weeks. Major issue is the common supporting functionality=20
> >>(ContextLoader, WebAppCtx,
> >>Databinding) between our Web stuff and our future Portlet=20
> >>stuff (and probably also the JSF stuff). Revising the=20
> >>supporting functionality right now (or for 1.1) is not an option imo.
> >>
> >>I probably can't avoid having to copy-and-paste a lot of code=20
> >>while experimenting and since that's *not* something we want=20
> >>to have in a release, I'm afraid you're right :(.
> >=20
> >=20
> > Several people have previously mentioned portlets and JSF. We are tryin=
g to
> > decide whether to implement portlets in our next project, or just stick=
 to
> > include files and/or something like Sitemesh, Tiles etc.
> >=20
> > Regarding portlets, there is the Pico-based Exo project
> > (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/plut=
o/).
> > Has anyone done any work on integrating portlets, JSF or projects such =
as
> > these into Spring? Would anyone be willing and have time to collaborate=
 on
> > this?
> >=20
> > Best regards
> > Ben
> >=20
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
--=20
************************
Nadeem Bitar
Software Engineer
IzuCode, LLC
858-337-6159
5230 Fiore Terrace #k208
San Diego, Ca 92122
************************=20

RE: [Springframework-developer] Portlet and JSFs

[<jef...@si...>]

> we'll need something workable in about a month <

Us too! 

Jeff W. Boring 




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of William G. Thompson, Jr.
Sent: Tuesday, April 13, 2004 11:13 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
> 
> 
> yes. I start work next week for a new company where I'll be developing a
> portal product. I have experience with Spring & Hibernate but have only
used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal. uPortal
> has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is not
ready
> yet but they report good progress.
> 
> If a Spring PortletDispatcher supported JSR-168 then it seems like it
would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work 
out right for us we'll need something workable in about a month...and 
hopefully in an official Spring release by August.

later.
Bill


> 
> Jeff W. Boring 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> Hi
> 
> 
>>JSF and Portlet functionality don't have to be provided in 
>>one and the same release. I have been looking a bit into the 
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of 
>>weeks. Major issue is the common supporting functionality 
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet 
>>stuff (and probably also the JSF stuff). Revising the 
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code 
>>while experimenting and since that's *not* something we want 
>>to have in a release, I'm afraid you're right :(.
> 
> 
> Several people have previously mentioned portlets and JSF. We are trying
to
> decide whether to implement portlets in our next project, or just stick to
> include files and/or something like Sitemesh, Tiles etc.
> 
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such as
> these into Spring? Would anyone be willing and have time to collaborate on
> this?
> 
> Best regards
> Ben
> 
> 



-------------------------------------------------------
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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Dmitriy K. <dko...@ru...>]

+1 Portlet! Portlet! Portlet! ;-))

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
jef...@si...
Sent: Tuesday, April 13, 2004 12:11 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


> we'll need something workable in about a month <

Us too!=20

Jeff W. Boring=20




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
William G. Thompson, Jr.
Sent: Tuesday, April 13, 2004 11:13 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
>=20
>=20
> yes. I start work next week for a new company where I'll be developing =

> a portal product. I have experience with Spring & Hibernate but have=20
> only
used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal.=20
> uPortal has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) =

> is not
ready
> yet but they report good progress.
>=20
> If a Spring PortletDispatcher supported JSR-168 then it seems like it
would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work=20
out right for us we'll need something workable in about a month...and=20
hopefully in an official Spring release by August.

later.
Bill


>=20
> Jeff W. Boring
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On=20
> Behalf Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
>=20
>=20
> Hi
>=20
>=20
>>JSF and Portlet functionality don't have to be provided in
>>one and the same release. I have been looking a bit into the=20
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of
>>weeks. Major issue is the common supporting functionality=20
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet=20
>>stuff (and probably also the JSF stuff). Revising the=20
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code
>>while experimenting and since that's *not* something we want=20
>>to have in a release, I'm afraid you're right :(.
>=20
>=20
> Several people have previously mentioned portlets and JSF. We are=20
> trying
to
> decide whether to implement portlets in our next project, or just=20
> stick to include files and/or something like Sitemesh, Tiles etc.
>=20
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such =

> as these into Spring? Would anyone be willing and have time to=20
> collaborate on this?
>=20
> Best regards
> Ben
>=20
>=20



-------------------------------------------------------
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=3Dcli=
ck
_______________________________________________
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=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Faizan H. <fa...@ru...>]

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
>=20
>=20
>>Rutgers is very interested in Spring support for the Portlet=20
>>API in the form of a PortletDispatcher as it were.  We run=20
>>the uPortal[1] platform and the latest release embeds Pluto. =20
>>We are just now embarking on dev cycle for new porlets that=20
>>takes us thru september, if possible these new portlets would=20
>>live behind a Spring PortletDispatcher.
>>
>>We have had some preliminary dicussions with Alef about what=20
>>it might look like, and should be in a better positition to=20
>>try out some ideas/code in a few weeks.
>=20
>=20
> 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)?
>=20

So far all of our Spring apps are "traditional"; leveraging the full=20
compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction,=20
ApplicationContext, declaritive transaction management, AOP, etc.) and=20
living in a dedicated Servlet context.

We have used Spring DAO/JDBC support for a few simple Channels=20
(Portlets), but that is the extent of it.

We are extremely pleased with the Spring development model and would=20
like to bring our portal project in line.

I don't think it should be too hard to bring SerlvetDispatcher behavior=20
to the Portlet API.  The big difference is that Portlets participated in =

a two step call (ActionRequest/Response and RenderRequest/Response) and=20
also have additional lifecycle events, PortletMode (View, Edit,=20
Help,...) and WindowMode (min, max, normal, etc.) that impact behavior=20
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=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Faizan H. <fa...@ru...>]

+11 for portlets (since me and Dmitriy work together and one one makes =
us
eleven this is called synergy ;-))

Faizan=20


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, April 13, 2004 1:12 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs

+1 Portlet! Portlet! Portlet! ;-))

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
jef...@si...
Sent: Tuesday, April 13, 2004 12:11 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


> we'll need something workable in about a month <

Us too!=20

Jeff W. Boring=20




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
William G. Thompson, Jr.
Sent: Tuesday, April 13, 2004 11:13 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


jef...@si... wrote:
>>Would anyone be willing and have time to collaborate on this?
>=20
>=20
> yes. I start work next week for a new company where I'll be developing =

> a portal product. I have experience with Spring & Hibernate but have=20
> only
used
> Struts as the MVC. I am currently evaluating Jetspeed and uPortal.=20
> uPortal has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) =

> is not
ready
> yet but they report good progress.
>=20
> If a Spring PortletDispatcher supported JSR-168 then it seems like it
would
> work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?

Exactly!

  What
> release of Spring would the PortletDispatcher be in, 1.01 or 1.1?

I would push for as soon as it is fully baked...for the timing to work=20
out right for us we'll need something workable in about a month...and=20
hopefully in an official Spring release by August.

later.
Bill


>=20
> Jeff W. Boring
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On=20
> Behalf Of Ben Alex
> Sent: Friday, April 09, 2004 2:33 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
>=20
>=20
> Hi
>=20
>=20
>>JSF and Portlet functionality don't have to be provided in
>>one and the same release. I have been looking a bit into the=20
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of
>>weeks. Major issue is the common supporting functionality=20
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet=20
>>stuff (and probably also the JSF stuff). Revising the=20
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code
>>while experimenting and since that's *not* something we want=20
>>to have in a release, I'm afraid you're right :(.
>=20
>=20
> Several people have previously mentioned portlets and JSF. We are=20
> trying
to
> decide whether to implement portlets in our next project, or just=20
> stick to include files and/or something like Sitemesh, Tiles etc.
>=20
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such =

> as these into Spring? Would anyone be willing and have time to=20
> collaborate on this?
>=20
> Best regards
> Ben
>=20
>=20



-------------------------------------------------------
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=3Dcli=
ck
_______________________________________________
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=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
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

RE: [Springframework-developer] Portlet and JSFs

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

The site is unreachable...

-----Original Message-----
From: Nadeem Bitar [mailto:na...@ea...] 
Sent: Tuesday, April 13, 2004 1:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


On 火, 2004-04-13 at 11:13 -0400, William G. Thompson, Jr. wrote:

> jef...@si... wrote:
> >>Would anyone be willing and have time to collaborate on this?
> > 
> > 
> > yes. I start work next week for a new company where I'll be 
> > developing a portal product. I have experience with Spring & 
> > Hibernate but have only used Struts as the MVC. I am currently 
> > evaluating Jetspeed and uPortal. uPortal has a 168-portlet adaptor 
> > out now. Jetspeed-2 (based on Pluto) is not ready yet but they 
> > report good progress.
> > 

Have a look at http://www.gridsphere.org/gridsphere/gridsphere 

> > If a Spring PortletDispatcher supported JSR-168 then it seems like 
> > it would work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this 
> > right?
> 
> Exactly!
> 
>   What
> > release of Spring would the PortletDispatcher be in, 1.01 or 1.1?
> 
> I would push for as soon as it is fully baked...for the timing to work
> out right for us we'll need something workable in about a month...and 
> hopefully in an official Spring release by August.
> 
> later.
> Bill
> 
> 
> > 
> > Jeff W. Boring
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On 
> > Behalf Of Ben Alex
> > Sent: Friday, April 09, 2004 2:33 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> > 
> > 
> > Hi
> > 
> > 
> >>JSF and Portlet functionality don't have to be provided in
> >>one and the same release. I have been looking a bit into the 
> >>portlet stuff and it doesn't same all that difficult.
> >>
> >>I think I'll experiment with it during the next couple of
> >>weeks. Major issue is the common supporting functionality 
> >>(ContextLoader, WebAppCtx,
> >>Databinding) between our Web stuff and our future Portlet 
> >>stuff (and probably also the JSF stuff). Revising the 
> >>supporting functionality right now (or for 1.1) is not an option imo.
> >>
> >>I probably can't avoid having to copy-and-paste a lot of code
> >>while experimenting and since that's *not* something we want 
> >>to have in a release, I'm afraid you're right :(.
> > 
> > 
> > Several people have previously mentioned portlets and JSF. We are 
> > trying to decide whether to implement portlets in our next project, 
> > or just stick to include files and/or something like Sitemesh, Tiles 
> > etc.
> > 
> > Regarding portlets, there is the Pico-based Exo project
> > (http://exo.sourceforge.net/) and Pluto 
> > (http://jakarta.apache.org/pluto/).
> > Has anyone done any work on integrating portlets, JSF or projects such
as
> > these into Spring? Would anyone be willing and have time to collaborate
on
> > this?
> > 
> > Best regards
> > Ben
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> 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_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-- 
************************
Nadeem Bitar
Software Engineer
IzuCode, LLC
858-337-6159
5230 Fiore Terrace #k208
San Diego, Ca 92122
************************ 



-------------------------------------------------------
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_id70&alloc_id638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

[<jue...@we...>]

> 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?

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 the form of a PortletDispatcher as it were.  We run
>>the uPortal[1] platform and the latest release embeds Pluto.=20
>>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


-------------------------------------------------------
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=3Dcli=
ck
_______________________________________________
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

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
> 

Re: [Springframework-developer] Portlet and JSFs

[Eduardo I. I. <zi...@su...>]

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?
> 
> Juergen

While in most cases a Portlet should be simple (just display some info), 
sometimes one portlet can be a complete web application in itself. In this case, 
having an MVC framework can make a huge difference. Imagine implementing a whole 
web application inside a servlet doPost(), and no framework underneath. With 
portlets you only have doView() to do the same thing...

A PortletDispatcher should be very similar to ServletDispatcher and reuse 
everything that is possible from the actual mvc framework. Ideally, implementing 
a portlet with Spring should be the same as implementing a servlet.

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

RE: [Springframework-developer] Portlet and JSFs

[<jef...@si...>]

> Have a look at http://www.gridsphere.org/gridsphere/gridsphere <

Looks very good. Are there any public sites running gridsphere? URL's?

Jeff W. Boring=20



-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
Nadeem Bitar
Sent: Tuesday, April 13, 2004 1:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


On =B2=D0, 2004-04-13 at 11:13 -0400, William G. Thompson, Jr. wrote:

> jef...@si... wrote:
> >>Would anyone be willing and have time to collaborate on this?
> >=20
> >=20
> > yes. I start work next week for a new company where I'll be =
developing a
> > portal product. I have experience with Spring & Hibernate but have =
only
used
> > Struts as the MVC. I am currently evaluating Jetspeed and uPortal.
uPortal
> > has a 168-portlet adaptor out now. Jetspeed-2 (based on Pluto) is =
not
ready
> > yet but they report good progress.
> >=20

Have a look at http://www.gridsphere.org/gridsphere/gridsphere=20

> > If a Spring PortletDispatcher supported JSR-168 then it seems like =
it
would
> > work for Jetspeed-2 & uPortal (also LifeRay &eXo). Is this right?
>=20
> Exactly!
>=20
>   What
> > release of Spring would the PortletDispatcher be in, 1.01 or 1.1?
>=20
> I would push for as soon as it is fully baked...for the timing to =
work=20
> out right for us we'll need something workable in about a month...and =

> hopefully in an official Spring release by August.
>=20
> later.
> Bill
>=20
>=20
> >=20
> > Jeff W. Boring=20
> >=20
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On =
Behalf
> > Of Ben Alex
> > Sent: Friday, April 09, 2004 2:33 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >=20
> >=20
> > Hi
> >=20
> >=20
> >>JSF and Portlet functionality don't have to be provided in=20
> >>one and the same release. I have been looking a bit into the=20
> >>portlet stuff and it doesn't same all that difficult.
> >>
> >>I think I'll experiment with it during the next couple of=20
> >>weeks. Major issue is the common supporting functionality=20
> >>(ContextLoader, WebAppCtx,
> >>Databinding) between our Web stuff and our future Portlet=20
> >>stuff (and probably also the JSF stuff). Revising the=20
> >>supporting functionality right now (or for 1.1) is not an option =
imo.
> >>
> >>I probably can't avoid having to copy-and-paste a lot of code=20
> >>while experimenting and since that's *not* something we want=20
> >>to have in a release, I'm afraid you're right :(.
> >=20
> >=20
> > Several people have previously mentioned portlets and JSF. We are =
trying
to
> > decide whether to implement portlets in our next project, or just =
stick
to
> > include files and/or something like Sitemesh, Tiles etc.
> >=20
> > Regarding portlets, there is the Pico-based Exo project
> > (http://exo.sourceforge.net/) and Pluto
(http://jakarta.apache.org/pluto/).
> > Has anyone done any work on integrating portlets, JSF or projects =
such
as
> > these into Spring? Would anyone be willing and have time to =
collaborate
on
> > this?
> >=20
> > Best regards
> > Ben
> >=20
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
--=20
************************
Nadeem Bitar
Software Engineer
IzuCode, LLC
858-337-6159
5230 Fiore Terrace #k208
San Diego, Ca 92122
************************=20



-------------------------------------------------------
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

Re: [Springframework-developer] Portlet and JSFs

[<jue...@we...>]

But what criteria do you base your dispatching on when there's no URL? =
Request parameters?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Eduardo Issao Ito
Gesendet: Di 13.04.2004 22:15
An: spr...@li...
Betreff: Re: [Springframework-developer] Portlet and JSFs



j=FCrgen h=F6ller [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?
>
> Juergen

While in most cases a Portlet should be simple (just display some info),
sometimes one portlet can be a complete web application in itself. In =
this case,
having an MVC framework can make a huge difference. Imagine implementing =
a whole
web application inside a servlet doPost(), and no framework underneath. =
With
portlets you only have doView() to do the same thing...

A PortletDispatcher should be very similar to ServletDispatcher and =
reuse
everything that is possible from the actual mvc framework. Ideally, =
implementing
a portlet with Spring should be the same as implementing a servlet.



-------------------------------------------------------
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=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

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

jürgen höller [werk3AT] wrote:
> But what criteria do you base your dispatching on when there's no URL? Request parameters?

yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some 
state...

and of course the other tricky bit is the two step 
call...ActionRequest/Response and then some time later the 
RenderRequest/Response.

>  
> Juergen
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Eduardo Issao Ito
> Gesendet: Di 13.04.2004 22:15
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Portlet and JSFs
> 
> 
> 
> 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?
>>
>>Juergen
> 
> 
> While in most cases a Portlet should be simple (just display some info),
> sometimes one portlet can be a complete web application in itself. In this case,
> having an MVC framework can make a huge difference. Imagine implementing a whole
> web application inside a servlet doPost(), and no framework underneath. With
> portlets you only have doView() to do the same thing...
> 
> A PortletDispatcher should be very similar to ServletDispatcher and reuse
> everything that is possible from the actual mvc framework. Ideally, implementing
> a portlet with Spring should be the same as implementing a servlet.
> 
> 

RE: [Springframework-developer] Portlet and JSFs

[Alef A. <al...@jt...>]

Ok, back in town ;-).

I think an approach of making the context available is a good first =
step.
From there later on we could possibly extend things to include mappings
based on portal mode, window state and maybe other criteria. But since =
I'm
seeing a lot of code getting duplicated if we go ahead there, I want to =
take
things slowly to see what the other options are.

To get the context available, I think it's best to create something like =
a
FrameworkPortlet (similar to the FrameworkServlet). This allows for =
further
extension later on (possibly the creation of a DispatcherPortlet if we =
need
it).

So: FrameworkPortlet extends PortletBean extends GenericPortlet,=20
offering the same functionality as the FrameworkServlet. I think =
extending
ApplicationContext to get a PortletApplicationContext is needed as well, =
to
allow for access to the PortletContext (instead of the ServletContext).

This is the approach I've been taking last time I spent time on it. If =
we
can continue this discussion a bit to see what everybody thinks, then =
I'll
probably be able to implement something tomorrow, Friday and over the
weekend (got some stuff lying around already so it shouldn't be that =
hard).

Regards,
Alef

=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of William G. Thompson, Jr.
> Sent: Wednesday, April 14, 2004 1:30 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
> > But what criteria do you base your dispatching on when there's no =
URL?
> Request parameters?
>=20
> yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some
> state...
>=20
> and of course the other tricky bit is the two step
> call...ActionRequest/Response and then some time later the
> RenderRequest/Response.
>=20
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im =
Auftrag
> von Eduardo Issao Ito
> > Gesendet: Di 13.04.2004 22:15
> > An: spr...@li...
> > Betreff: Re: [Springframework-developer] Portlet and JSFs
> >
> >
> >
> > j=FCrgen h=F6ller [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?
> >>
> >>Juergen
> >
> >
> > While in most cases a Portlet should be simple (just display some =
info),
> > sometimes one portlet can be a complete web application in itself. =
In
> this case,
> > having an MVC framework can make a huge difference. Imagine =
implementing
> a whole
> > web application inside a servlet doPost(), and no framework =
underneath.
> With
> > portlets you only have doView() to do the same thing...
> >
> > A PortletDispatcher should be very similar to ServletDispatcher and
> reuse
> > everything that is possible from the actual mvc framework. Ideally,
> implementing
> > a portlet with Spring should be the same as implementing a servlet.
> >
> >
>=20
>=20
> -------------------------------------------------------
> 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

RE: [Springframework-developer] Portlet and JSFs

[Dmitriy K. <dko...@ru...>]

Here what the eXo platform did with Bridges/Adapters approach:
http://exo.sourceforge.net/bridges-intro.html (the source code is =
available)

Regards,
Dmitriy.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Alef Arendsen
Sent: Wednesday, April 14, 2004 5:40 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


Ok, back in town ;-).

I think an approach of making the context available is a good first =
step.
From there later on we could possibly extend things to include mappings
based on portal mode, window state and maybe other criteria. But since =
I'm
seeing a lot of code getting duplicated if we go ahead there, I want to =
take
things slowly to see what the other options are.

To get the context available, I think it's best to create something like =
a
FrameworkPortlet (similar to the FrameworkServlet). This allows for =
further
extension later on (possibly the creation of a DispatcherPortlet if we =
need
it).

So: FrameworkPortlet extends PortletBean extends GenericPortlet,=20
offering the same functionality as the FrameworkServlet. I think =
extending
ApplicationContext to get a PortletApplicationContext is needed as well, =
to
allow for access to the PortletContext (instead of the ServletContext).

This is the approach I've been taking last time I spent time on it. If =
we
can continue this discussion a bit to see what everybody thinks, then =
I'll
probably be able to implement something tomorrow, Friday and over the
weekend (got some stuff lying around already so it shouldn't be that =
hard).

Regards,
Alef

=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of William G. Thompson, Jr.
> Sent: Wednesday, April 14, 2004 1:30 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
> > But what criteria do you base your dispatching on when there's no=20
> > URL?
> Request parameters?
>=20
> yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some=20
> state...
>=20
> and of course the other tricky bit is the two step=20
> call...ActionRequest/Response and then some time later the=20
> RenderRequest/Response.
>=20
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im=20
> > Auftrag
> von Eduardo Issao Ito
> > Gesendet: Di 13.04.2004 22:15
> > An: spr...@li...
> > Betreff: Re: [Springframework-developer] Portlet and JSFs
> >
> >
> >
> > j=FCrgen h=F6ller [werk3AT] wrote:
> >
> >>>Portlets can not access the URL that the client used to initiate=20
> >>>the
> request on the portal.
> >>
> >>
> >>While that makes sense, it effectively makes me wonder whether we=20
> >>need a
> Portlet dispatcher: With Servlets, dispatching is all about flexible=20
> URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks,=20
> similar to doGet, doPost, etc from the Servlet API.
> >>
> >>So for typical Portlets, it's probably most important to allow for=20
> >>easy
> access to Spring facilities from those methods, rather than dispatch=20
> 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
> >
> >
> > While in most cases a Portlet should be simple (just display some=20
> > info), sometimes one portlet can be a complete web application in=20
> > itself. In
> this case,
> > having an MVC framework can make a huge difference. Imagine=20
> > implementing
> a whole
> > web application inside a servlet doPost(), and no framework=20
> > underneath.
> With
> > portlets you only have doView() to do the same thing...
> >
> > A PortletDispatcher should be very similar to ServletDispatcher and
> reuse
> > everything that is possible from the actual mvc framework. Ideally,
> implementing
> > a portlet with Spring should be the same as implementing a servlet.
> >
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of=20
> GenToo technologies. Learn everything from fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list=20
> 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

Re: [Springframework-developer] Portlet and JSFs

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

this also might help...
http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.html

Dmitriy Kopylenko wrote:
> Here what the eXo platform did with Bridges/Adapters approach:
> http://exo.sourceforge.net/bridges-intro.html (the source code is available)
> 
> Regards,
> Dmitriy.
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Alef Arendsen
> Sent: Wednesday, April 14, 2004 5:40 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
> 
> 
> Ok, back in town ;-).
> 
> I think an approach of making the context available is a good first step.
> From there later on we could possibly extend things to include mappings
> based on portal mode, window state and maybe other criteria. But since I'm
> seeing a lot of code getting duplicated if we go ahead there, I want to take
> things slowly to see what the other options are.
> 
> To get the context available, I think it's best to create something like a
> FrameworkPortlet (similar to the FrameworkServlet). This allows for further
> extension later on (possibly the creation of a DispatcherPortlet if we need
> it).
> 
> So: FrameworkPortlet extends PortletBean extends GenericPortlet, 
> offering the same functionality as the FrameworkServlet. I think extending
> ApplicationContext to get a PortletApplicationContext is needed as well, to
> allow for access to the PortletContext (instead of the ServletContext).
> 
> This is the approach I've been taking last time I spent time on it. If we
> can continue this discussion a bit to see what everybody thinks, then I'll
> probably be able to implement something tomorrow, Friday and over the
> weekend (got some stuff lying around already so it shouldn't be that hard).
> 
> Regards,
> Alef
> 
>  
> 
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On 
>>Behalf Of William G. Thompson, Jr.
>>Sent: Wednesday, April 14, 2004 1:30 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Portlet and JSFs
>>
>>jürgen höller [werk3AT] wrote:
>>
>>>But what criteria do you base your dispatching on when there's no 
>>>URL?
>>
>>Request parameters?
>>
>>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some 
>>state...
>>
>>and of course the other tricky bit is the two step 
>>call...ActionRequest/Response and then some time later the 
>>RenderRequest/Response.
>>
>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im 
>>>Auftrag
>>
>>von Eduardo Issao Ito
>>
>>>Gesendet: Di 13.04.2004 22:15
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-developer] Portlet and JSFs
>>>
>>>
>>>
>>>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?
>>
>>>>Juergen
>>>
>>>
>>>While in most cases a Portlet should be simple (just display some 
>>>info), sometimes one portlet can be a complete web application in 
>>>itself. In
>>
>>this case,
>>
>>>having an MVC framework can make a huge difference. Imagine 
>>>implementing
>>
>>a whole
>>
>>>web application inside a servlet doPost(), and no framework 
>>>underneath.
>>
>>With
>>
>>>portlets you only have doView() to do the same thing...
>>>
>>>A PortletDispatcher should be very similar to ServletDispatcher and
>>
>>reuse
>>
>>>everything that is possible from the actual mvc framework. Ideally,
>>
>>implementing
>>
>>>a portlet with Spring should be the same as implementing a servlet.
>>>
>>>
>>
>>
>>-------------------------------------------------------
>>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_id70&alloc_id638&op=click
>>_______________________________________________
>>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_id70&alloc_id638&op=click
> _______________________________________________
> 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_id70&alloc_id638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Alef A. <al...@jt...>]

Interesting approach they're taking. However, there are a couple of real
nasty things going on there as far as I can see.

In their bridges/adapters intro (using underlying controllers/actions =
for
both portlet- and servlet-based apps) they're mentioning two approaches;
either modifying the underlying framework in some way or modifying /
rewriting the HTML coming from the Servlet (which in this case would be =
the
Spring dispatcher servlet). I really don't like the last approach and
certainly do not think it should be part of a solution Spring is =
offering.
The first solution would be the way to go but that means we'll have to
modify/rewrite the current MVC package, or at least, the infrastructural
code. This is a non-option of course.

To be honest I can't think of a way to get our current controller
infrastructure to work with portlets, except for manually forwarding an
incoming ActionRequest to a Servlet using the PortletRequestDispatcher. =
This
is only allowed when executing the render method of the Portlet =
interface.
Forcing users to only use the render method is not really a good thing =
to do
IMHO.

Getting the applicationcontext available through a FrameworkPortlet is =
the
first step I think and this is one thing that should be available in =
Spring
core (it's only a couple of classes). How to go on after that is still
unclear for me.

Opinions?

Alef






> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of William G. Thompson, Jr.
> Sent: Wednesday, April 14, 2004 3:16 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>=20
> this also might help...
> =
http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.html
>=20
> Dmitriy Kopylenko wrote:
> > Here what the eXo platform did with Bridges/Adapters approach:
> > http://exo.sourceforge.net/bridges-intro.html (the source code is
> available)
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On =
Behalf
> Of
> > Alef Arendsen
> > Sent: Wednesday, April 14, 2004 5:40 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > Ok, back in town ;-).
> >
> > I think an approach of making the context available is a good first
> step.
> > From there later on we could possibly extend things to include =
mappings
> > based on portal mode, window state and maybe other criteria. But =
since
> I'm
> > seeing a lot of code getting duplicated if we go ahead there, I want =
to
> take
> > things slowly to see what the other options are.
> >
> > To get the context available, I think it's best to create something =
like
> a
> > FrameworkPortlet (similar to the FrameworkServlet). This allows for
> further
> > extension later on (possibly the creation of a DispatcherPortlet if =
we
> need
> > it).
> >
> > So: FrameworkPortlet extends PortletBean extends GenericPortlet,
> > offering the same functionality as the FrameworkServlet. I think
> extending
> > ApplicationContext to get a PortletApplicationContext is needed as =
well,
> to
> > allow for access to the PortletContext (instead of the =
ServletContext).
> >
> > This is the approach I've been taking last time I spent time on it. =
If
> we
> > can continue this discussion a bit to see what everybody thinks, =
then
> I'll
> > probably be able to implement something tomorrow, Friday and over =
the
> > weekend (got some stuff lying around already so it shouldn't be that
> hard).
> >
> > Regards,
> > Alef
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On
> >>Behalf Of William G. Thompson, Jr.
> >>Sent: Wednesday, April 14, 2004 1:30 AM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Portlet and JSFs
> >>
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>>But what criteria do you base your dispatching on when there's no
> >>>URL?
> >>
> >>Request parameters?
> >>
> >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe =
some
> >>state...
> >>
> >>and of course the other tricky bit is the two step
> >>call...ActionRequest/Response and then some time later the
> >>RenderRequest/Response.
> >>
> >>
> >>>Juergen
> >>>
> >>>
> >>>________________________________
> >>>
> >>>Von: spr...@li... im
> >>>Auftrag
> >>
> >>von Eduardo Issao Ito
> >>
> >>>Gesendet: Di 13.04.2004 22:15
> >>>An: spr...@li...
> >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> >>>
> >>>
> >>>
> >>>j=FCrgen h=F6ller [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?
> >>
> >>>>Juergen
> >>>
> >>>
> >>>While in most cases a Portlet should be simple (just display some
> >>>info), sometimes one portlet can be a complete web application in
> >>>itself. In
> >>
> >>this case,
> >>
> >>>having an MVC framework can make a huge difference. Imagine
> >>>implementing
> >>
> >>a whole
> >>
> >>>web application inside a servlet doPost(), and no framework
> >>>underneath.
> >>
> >>With
> >>
> >>>portlets you only have doView() to do the same thing...
> >>>
> >>>A PortletDispatcher should be very similar to ServletDispatcher and
> >>
> >>reuse
> >>
> >>>everything that is possible from the actual mvc framework. Ideally,
> >>
> >>implementing
> >>
> >>>a portlet with Spring should be the same as implementing a servlet.
> >>>
> >>>
> >>
> >>
> >>-------------------------------------------------------
> >>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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> >
> > -------------------------------------------------------
> > 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
>=20
>=20
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Portlet and JSFs

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

Alef Arendsen wrote:
[snip]
> 
> To be honest I can't think of a way to get our current controller
> infrastructure to work with portlets, except for manually forwarding an
> incoming ActionRequest to a Servlet using the PortletRequestDispatcher. This
> is only allowed when executing the render method of the Portlet interface.
> Forcing users to only use the render method is not really a good thing to do
> IMHO.
> 
> Getting the applicationcontext available through a FrameworkPortlet is the
> first step I think and this is one thing that should be available in Spring
> core (it's only a couple of classes). How to go on after that is still
> unclear for me.

That sounds like a good first step...we may need a Portlet specific 
controller/handler infrastructure since many of the "normal" web app 
handler mappings don't make sense is this context.  We can start 
building some services on top of FrameworkPortlet as soon as its ready 
then contribute ideas as we go along.

RE: [Springframework-developer] Portlet and JSFs

[Dmitriy K. <dko...@ru...>]

And here is eXo's own Portlet framework:
http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.html

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Wednesday, April 14, 2004 8:58 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


Here what the eXo platform did with Bridges/Adapters approach:
http://exo.sourceforge.net/bridges-intro.html (the source code is =
available)

Regards,
Dmitriy.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Alef Arendsen
Sent: Wednesday, April 14, 2004 5:40 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet and JSFs


Ok, back in town ;-).

I think an approach of making the context available is a good first =
step.
From there later on we could possibly extend things to include mappings
based on portal mode, window state and maybe other criteria. But since =
I'm
seeing a lot of code getting duplicated if we go ahead there, I want to =
take
things slowly to see what the other options are.

To get the context available, I think it's best to create something like =
a
FrameworkPortlet (similar to the FrameworkServlet). This allows for =
further
extension later on (possibly the creation of a DispatcherPortlet if we =
need
it).

So: FrameworkPortlet extends PortletBean extends GenericPortlet,=20
offering the same functionality as the FrameworkServlet. I think =
extending
ApplicationContext to get a PortletApplicationContext is needed as well, =
to
allow for access to the PortletContext (instead of the ServletContext).

This is the approach I've been taking last time I spent time on it. If =
we
can continue this discussion a bit to see what everybody thinks, then =
I'll
probably be able to implement something tomorrow, Friday and over the
weekend (got some stuff lying around already so it shouldn't be that =
hard).

Regards,
Alef

=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
> Behalf Of William G. Thompson, Jr.
> Sent: Wednesday, April 14, 2004 1:30 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
> > But what criteria do you base your dispatching on when there's no
> > URL?
> Request parameters?
>=20
> yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some
> state...
>=20
> and of course the other tricky bit is the two step
> call...ActionRequest/Response and then some time later the=20
> RenderRequest/Response.
>=20
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im
> > Auftrag
> von Eduardo Issao Ito
> > Gesendet: Di 13.04.2004 22:15
> > An: spr...@li...
> > Betreff: Re: [Springframework-developer] Portlet and JSFs
> >
> >
> >
> > j=FCrgen h=F6ller [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,=20
> 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
> >
> >
> > While in most cases a Portlet should be simple (just display some
> > info), sometimes one portlet can be a complete web application in=20
> > itself. In
> this case,
> > having an MVC framework can make a huge difference. Imagine
> > implementing
> a whole
> > web application inside a servlet doPost(), and no framework
> > underneath.
> With
> > portlets you only have doView() to do the same thing...
> >
> > A PortletDispatcher should be very similar to ServletDispatcher and
> reuse
> > everything that is possible from the actual mvc framework. Ideally,
> implementing
> > a portlet with Spring should be the same as implementing a servlet.
> >
> >
>=20
>=20
> -------------------------------------------------------
> 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=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list=20
> 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



-------------------------------------------------------
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

RE: [Springframework-developer] Portlet and JSFs

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

BTW I've creataed "Portlet support" space in Confluence...



-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@ru...]=20
Sent: Wednesday, April 14, 2004 9:16 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


this also might help...
http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.html=


Dmitriy Kopylenko wrote:
> Here what the eXo platform did with Bridges/Adapters approach:=20
> http://exo.sourceforge.net/bridges-intro.html (the source code is=20
> available)
>=20
> Regards,
> Dmitriy.
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of Alef Arendsen
> Sent: Wednesday, April 14, 2004 5:40 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Portlet and JSFs
>=20
>=20
> Ok, back in town ;-).
>=20
> I think an approach of making the context available is a good first=20
> step. From there later on we could possibly extend things to include=20
> mappings based on portal mode, window state and maybe other criteria. =

> But since I'm seeing a lot of code getting duplicated if we go ahead=20
> there, I want to take things slowly to see what the other options =
are.
>=20
> To get the context available, I think it's best to create something=20
> like a FrameworkPortlet (similar to the FrameworkServlet). This =
allows=20
> for further extension later on (possibly the creation of a=20
> DispatcherPortlet if we need it).
>=20
> So: FrameworkPortlet extends PortletBean extends GenericPortlet,
> offering the same functionality as the FrameworkServlet. I think =
extending
> ApplicationContext to get a PortletApplicationContext is needed as =
well,
to
> allow for access to the PortletContext (instead of the =
ServletContext).
>=20
> This is the approach I've been taking last time I spent time on it. =
If=20
> we can continue this discussion a bit to see what everybody thinks,=20
> then I'll probably be able to implement something tomorrow, Friday =
and=20
> over the weekend (got some stuff lying around already so it shouldn't =

> be that hard).
>=20
> Regards,
> Alef
>=20
> =20
>=20
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On
>>Behalf Of William G. Thompson, Jr.
>>Sent: Wednesday, April 14, 2004 1:30 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Portlet and JSFs
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>>But what criteria do you base your dispatching on when there's no
>>>URL?
>>
>>Request parameters?
>>
>>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some
>>state...
>>
>>and of course the other tricky bit is the two step
>>call...ActionRequest/Response and then some time later the=20
>>RenderRequest/Response.
>>
>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im
>>>Auftrag
>>
>>von Eduardo Issao Ito
>>
>>>Gesendet: Di 13.04.2004 22:15
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-developer] Portlet and JSFs
>>>
>>>
>>>
>>>j=FCrgen h=F6ller [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,=20
>>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=20
>>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
>>>
>>>
>>>While in most cases a Portlet should be simple (just display some
>>>info), sometimes one portlet can be a complete web application in=20
>>>itself. In
>>
>>this case,
>>
>>>having an MVC framework can make a huge difference. Imagine
>>>implementing
>>
>>a whole
>>
>>>web application inside a servlet doPost(), and no framework
>>>underneath.
>>
>>With
>>
>>>portlets you only have doView() to do the same thing...
>>>
>>>A PortletDispatcher should be very similar to ServletDispatcher and
>>
>>reuse
>>
>>>everything that is possible from the actual mvc framework. Ideally,
>>
>>implementing
>>
>>>a portlet with Spring should be the same as implementing a servlet.
>>>
>>>
>>
>>
>>-------------------------------------------------------
>>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=20
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
>>_______________________________________________
>>Springframework-developer mailing list=20
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer=

>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> 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=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list=20
> 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=3D1470&alloc_id=3D3638&op=3Dcl=
ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet and JSFs

[Keith D. <kd...@cs...>]

I can't seem to find the action to create a new space--I am in JIRA
developers though.

Keith

----- Original Message -----=20
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Wednesday, April 14, 2004 9:33 AM
Subject: RE: [Springframework-developer] Portlet and JSFs


> BTW I've creataed "Portlet support" space in Confluence...
>
>
>
> -----Original Message-----
> From: William G. Thompson, Jr. [mailto:wg...@ru...]
> Sent: Wednesday, April 14, 2004 9:16 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>
>
> this also might help...
> http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.htm=
l
>
> Dmitriy Kopylenko wrote:
> > Here what the eXo platform did with Bridges/Adapters approach:
> > http://exo.sourceforge.net/bridges-intro.html (the source code is
> > available)
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On
> > Behalf Of Alef Arendsen
> > Sent: Wednesday, April 14, 2004 5:40 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > Ok, back in town ;-).
> >
> > I think an approach of making the context available is a good first
> > step. From there later on we could possibly extend things to include
> > mappings based on portal mode, window state and maybe other criteria.
> > But since I'm seeing a lot of code getting duplicated if we go ahead
> > there, I want to take things slowly to see what the other options are=
.
> >
> > To get the context available, I think it's best to create something
> > like a FrameworkPortlet (similar to the FrameworkServlet). This allow=
s
> > for further extension later on (possibly the creation of a
> > DispatcherPortlet if we need it).
> >
> > So: FrameworkPortlet extends PortletBean extends GenericPortlet,
> > offering the same functionality as the FrameworkServlet. I think
extending
> > ApplicationContext to get a PortletApplicationContext is needed as we=
ll,
> to
> > allow for access to the PortletContext (instead of the ServletContext=
).
> >
> > This is the approach I've been taking last time I spent time on it. I=
f
> > we can continue this discussion a bit to see what everybody thinks,
> > then I'll probably be able to implement something tomorrow, Friday an=
d
> > over the weekend (got some stuff lying around already so it shouldn't
> > be that hard).
> >
> > Regards,
> > Alef
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On
> >>Behalf Of William G. Thompson, Jr.
> >>Sent: Wednesday, April 14, 2004 1:30 AM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Portlet and JSFs
> >>
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>>But what criteria do you base your dispatching on when there's no
> >>>URL?
> >>
> >>Request parameters?
> >>
> >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some
> >>state...
> >>
> >>and of course the other tricky bit is the two step
> >>call...ActionRequest/Response and then some time later the
> >>RenderRequest/Response.
> >>
> >>
> >>>Juergen
> >>>
> >>>
> >>>________________________________
> >>>
> >>>Von: spr...@li... im
> >>>Auftrag
> >>
> >>von Eduardo Issao Ito
> >>
> >>>Gesendet: Di 13.04.2004 22:15
> >>>An: spr...@li...
> >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> >>>
> >>>
> >>>
> >>>j=FCrgen h=F6ller [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 suppor=
t
> >>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
> >>>
> >>>
> >>>While in most cases a Portlet should be simple (just display some
> >>>info), sometimes one portlet can be a complete web application in
> >>>itself. In
> >>
> >>this case,
> >>
> >>>having an MVC framework can make a huge difference. Imagine
> >>>implementing
> >>
> >>a whole
> >>
> >>>web application inside a servlet doPost(), and no framework
> >>>underneath.
> >>
> >>With
> >>
> >>>portlets you only have doView() to do the same thing...
> >>>
> >>>A PortletDispatcher should be very similar to ServletDispatcher and
> >>
> >>reuse
> >>
> >>>everything that is possible from the actual mvc framework. Ideally,
> >>
> >>implementing
> >>
> >>>a portlet with Spring should be the same as implementing a servlet.
> >>>
> >>>
> >>
> >>
> >>-------------------------------------------------------
> >>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-develope=
r
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-develope=
r
> >
> >
> >
> > -------------------------------------------------------
> > 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-develope=
r
>
>
> -------------------------------------------------------
> 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=3Dc=
lick
> _______________________________________________
> 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=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet and JSFs

[Dmitriy K. <dko...@ru...>]

I've added jira-developers to be able to create spaces...

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Wednesday, April 14, 2004 11:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


I can't seem to find the action to create a new space--I am in JIRA
developers though.

Keith

----- Original Message -----=20
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Wednesday, April 14, 2004 9:33 AM
Subject: RE: [Springframework-developer] Portlet and JSFs


> BTW I've creataed "Portlet support" space in Confluence...
>
>
>
> -----Original Message-----
> From: William G. Thompson, Jr. [mailto:wg...@ru...]
> Sent: Wednesday, April 14, 2004 9:16 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>
>
> this also might help...=20
> http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.ht
> ml
>
> Dmitriy Kopylenko wrote:
> > Here what the eXo platform did with Bridges/Adapters approach:=20
> > http://exo.sourceforge.net/bridges-intro.html (the source code is
> > available)
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On=20
> > Behalf Of Alef Arendsen
> > Sent: Wednesday, April 14, 2004 5:40 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > Ok, back in town ;-).
> >
> > I think an approach of making the context available is a good first=20
> > step. From there later on we could possibly extend things to include =

> > mappings based on portal mode, window state and maybe other=20
> > criteria. But since I'm seeing a lot of code getting duplicated if=20
> > we go ahead there, I want to take things slowly to see what the=20
> > other options are.
> >
> > To get the context available, I think it's best to create something=20
> > like a FrameworkPortlet (similar to the FrameworkServlet). This=20
> > allows for further extension later on (possibly the creation of a=20
> > DispatcherPortlet if we need it).
> >
> > So: FrameworkPortlet extends PortletBean extends GenericPortlet,=20
> > offering the same functionality as the FrameworkServlet. I think
extending
> > ApplicationContext to get a PortletApplicationContext is needed as=20
> > well,
> to
> > allow for access to the PortletContext (instead of the=20
> > ServletContext).
> >
> > This is the approach I've been taking last time I spent time on it.=20
> > If we can continue this discussion a bit to see what everybody=20
> > thinks, then I'll probably be able to implement something tomorrow,=20
> > Friday and over the weekend (got some stuff lying around already so=20
> > it shouldn't be that hard).
> >
> > Regards,
> > Alef
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On=20
> >>Behalf Of William G. Thompson, Jr.
> >>Sent: Wednesday, April 14, 2004 1:30 AM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Portlet and JSFs
> >>
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>>But what criteria do you base your dispatching on when there's no=20
> >>>URL?
> >>
> >>Request parameters?
> >>
> >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe=20
> >>some state...
> >>
> >>and of course the other tricky bit is the two step=20
> >>call...ActionRequest/Response and then some time later the=20
> >>RenderRequest/Response.
> >>
> >>
> >>>Juergen
> >>>
> >>>
> >>>________________________________
> >>>
> >>>Von: spr...@li... im=20
> >>>Auftrag
> >>
> >>von Eduardo Issao Ito
> >>
> >>>Gesendet: Di 13.04.2004 22:15
> >>>An: spr...@li...
> >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> >>>
> >>>
> >>>
> >>>j=FCrgen h=F6ller [werk3AT] wrote:
> >>>
> >>>
> >>>>>Portlets can not access the URL that the client used to initiate=20
> >>>>>the
> >>
> >>request on the portal.
> >>
> >>>>
> >>>>While that makes sense, it effectively makes me wonder whether we=20
> >>>>need a
> >>
> >>Portlet dispatcher: With Servlets, dispatching is all about flexible =

> >>URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks,=20
> >>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=20
> >>support classes similar to the ones I just added for Struts come to=20
> >>my mind.
> >>
> >>>>This doesn't seem to be much effort at all. Am I on the wrong=20
> >>>>track
> >>
> >>here?
> >>
> >>>>Juergen
> >>>
> >>>
> >>>While in most cases a Portlet should be simple (just display some=20
> >>>info), sometimes one portlet can be a complete web application in=20
> >>>itself. In
> >>
> >>this case,
> >>
> >>>having an MVC framework can make a huge difference. Imagine=20
> >>>implementing
> >>
> >>a whole
> >>
> >>>web application inside a servlet doPost(), and no framework=20
> >>>underneath.
> >>
> >>With
> >>
> >>>portlets you only have doView() to do the same thing...
> >>>
> >>>A PortletDispatcher should be very similar to ServletDispatcher and
> >>
> >>reuse
> >>
> >>>everything that is possible from the actual mvc framework. Ideally,
> >>
> >>implementing
> >>
> >>>a portlet with Spring should be the same as implementing a servlet.
> >>>
> >>>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO=20
> >>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=20
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-develop
> >>er
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO=20
> > 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=20
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develop
> > er
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO=20
> > 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=20
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develop
> > er
>
>
> -------------------------------------------------------
> 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=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list=20
> 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=20
> GenToo technologies. Learn everything from fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list=20
> 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