Follow up to last week's question on desktop pipeline

["Tallamraju, Raman" <Ra...@FMR.COM>]

Hi All,

Here's a follow up to my last post in which I reported that the
response.sendRedirect doesn't seem to be working in desktop pipeline.
After looking into this in some more detail, here are my findings so
far:

We have a inventory portlet that extends PortletSelector. In the
doView() of this portlet, we filter based on page affinity and display
the portlets (as a list) that do not already exist on the page. Each
hypertext link in this list has been created via a
response.createActionURL() on to which we've set a custom parameter that
carries the portlet name. When this URL is clicked by a user, in the
jetspeed pipeline, we see a preview of this portlet as expected (request
goes through portal pipeline in this case). However, in the desktop
pipeline (where it goes through action pipeline) - it just displays the
default page.

Here's the sequence of events that happen when a user clicks on a
portlet preview link:

1. Inventory portlet's processAction method is called
2. Using the portlet name set as a parameter on the action URL, we
retrieve the portlet definition object from the registry
3. requestContext.getPortalURL().getBasePath() gives us the base path
upon which we build the rest of the URL
4. finally, response.sendRedirect is called on this URL (in our case
it's
/fep/action/portlets/boxPortal/displayappraisalreport.psml?windowState=m
aximized)

I don't know why the path through the action pipeline here is failing in
the desktop pipeline (the portal pipeline is used in the case when we
don't use desktop pipeline and everything works correctly in this case).

When I hardcode
/fep/portlet/portlets/boxPortal/displayappraisalreport.psml?windowState=
maximized, it works fine in the jetspeed pipeline but causes the target
portlet content to show up inside the portlets that already exist on the
page in the case of desktop pipeline.

Can somebody help me understand what's going on here and why this piece
of code that works fine in the jetspeed pipeline won't work in the
desktop pipeline?

Thanks,
Raman

RE: Follow up to last week's question on desktop pipeline

[Steve Milek <s....@comcast.net>]

The desktop client-side is not looking for a 302 response to an action
pipeline request. This should be a simple change. I'll create a test portlet
with a processAction that calls sendRedirect.

>From what I can gather, this should be enough to solve the problem. Please
let me know if you think I may not be getting the whole picture.

-----Original Message-----
From: Tallamraju, Raman [mailto:Raman.Tallamraju@FMR.COM]
Sent: Monday, December 11, 2006 3:10 PM
To: Jetspeed Developers List
Cc: jetspeed-dev@jakarta.apache.org
Subject: Follow up to last week's question on desktop pipeline


Hi All,

Here's a follow up to my last post in which I reported that the
response.sendRedirect doesn't seem to be working in desktop pipeline.
After looking into this in some more detail, here are my findings so
far:

We have a inventory portlet that extends PortletSelector. In the
doView() of this portlet, we filter based on page affinity and display
the portlets (as a list) that do not already exist on the page. Each
hypertext link in this list has been created via a
response.createActionURL() on to which we've set a custom parameter that
carries the portlet name. When this URL is clicked by a user, in the
jetspeed pipeline, we see a preview of this portlet as expected (request
goes through portal pipeline in this case). However, in the desktop
pipeline (where it goes through action pipeline) - it just displays the
default page.

Here's the sequence of events that happen when a user clicks on a
portlet preview link:

1. Inventory portlet's processAction method is called
2. Using the portlet name set as a parameter on the action URL, we
retrieve the portlet definition object from the registry
3. requestContext.getPortalURL().getBasePath() gives us the base path
upon which we build the rest of the URL
4. finally, response.sendRedirect is called on this URL (in our case
it's
/fep/action/portlets/boxPortal/displayappraisalreport.psml?windowState=m
aximized)

I don't know why the path through the action pipeline here is failing in
the desktop pipeline (the portal pipeline is used in the case when we
don't use desktop pipeline and everything works correctly in this case).

When I hardcode
/fep/portlet/portlets/boxPortal/displayappraisalreport.psml?windowState=
maximized, it works fine in the jetspeed pipeline but causes the target
portlet content to show up inside the portlets that already exist on the
page in the case of desktop pipeline.

Can somebody help me understand what's going on here and why this piece
of code that works fine in the jetspeed pipeline won't work in the
desktop pipeline?

Thanks,
Raman




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org