portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: JS 2.1 - render phase not called when actionResponse.sendRedirect used
Date Tue, 20 Mar 2007 17:35:00 GMT

On Mar 20, 2007, at 9:11 AM, Aaron Evans wrote:

> Guys,
> I think this is a bug. If you agree, I shall create a JIRA issue.  If
> you disagree, any suggestions for a work around would be appreciated.
>
> Here's the scenario:
>
> 1. User logs in and browses to pageA.psml.  When portletX on
> pageA.psml renders, it's content depends on an attribute, 'attributeP'
> that is stored in the session with PORTLET_APPLICATION scope.
>
> 2. User then navigates to pageB.psml.  pageB.psml contains portletY
> which is part of the same application as portletX.
>
> 3. User clicks a portlet action link for portletY.  In the
> processAction method, attributeP's value is modified the response is
> then a redirect back to pageA.psml.
>
> 4. When the content from pageA.psml is sent to the client browser, it
> seems to be coming from some kind of cache.  The render phase for
> portletX is not being called.   However, this content is *stale*
> because the value of attributeP has changed and so the content for
> portletX will be different.
>
> Even if the user does a "hard" browser refresh or puts focus on the
> url bar and hits enter, you get the same result: the render phase for
> portletX is never called.
>
> In order to get portletX's render method to be called I have to click
> another action or render link in the page.
>
> We use this little "trick" extensively for portlets that manage data
> that is related.  Eg. I have a "Customer Manager" portal page.  They
> can click a link labeled "Show Users" and it brings them to the
> "Manage Users" page with the users for that customer in the results.
>

I believe the portal is behaving correctly in this case as its  
invalidating the current page only
The spec doesn't really address multiple page cases, leaving it open  
to interpretation

The way its behaving right now, only portlet windows on the same page  
are invalidated on an action, so windows on a different page are not  
invalidated

I think there are a couple of ways we could handle this :

* don't use portlet caching on your particular portlet (just remove  
the <expiration-cache> tag
* we could add a feature to handle this case, such as expiring all  
portlet windows in a portlet application during actions, or something  
similar





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


Mime
View raw message