portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David G. Powers" <jetspeed-...@pssp.com>
Subject Re: Portlet Caching problem - PER SESSION
Date Tue, 02 Apr 2002 02:11:35 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm working on an enhancement that could utilize per session caching.  If 
the cache key was made configurable per portlet or there was an option to 
include SESSIONID I would be grateful.

DP

==================================================================
If you're interested, I'm working on a WebPageProxyPortlet.  I'll give a 
quick rundown of how I'm doing it now for context....

- - Set up "Content" in DB/XML config files
	URL, get vars, post vars, username, password, etc...

- - WebPageProxyPortlet registered with "contentID" parameter

- - Jetspeed Start - All "Default Settings" for each contentID are loaded 
into a ServletContext attribute.

- - When a user requests a WebPageProxyPortlet item, the "Default Settings" 
for that user's instance are copied into their Session

- - The HTMLRewriter replaces <FORM> action attributes and <A>nchor and 
<AREA> href attributes with the url of a "PortletProxy" servlet.  The 
original action or href are placed in a hidden field or querystring field. 

- - When the user acts on a link or submits a form from within the 
WebPageProxyPortlet, control is passed to the PortletProxy.

- - The PortletProxy pushes the current settings for the contentID into the 
Session (new" url, post vars, cookies, auth tokens, etc.....) and then 
redirects back to the calling page. 

- - The calling page just loads the "current" settings for the requested 
contentID from the session and displays the rewritten results.
The cycle continues.

- - Backward navigation can be accomplished if the Session content attributes 
are maintained with a stack (I'm currently using a single instance with 
only a "restart" action, no "back 1 step" button")




DP






On Monday 01 April 2002 05:14 pm, Glenn Golden wrote:
> Here's what I think we CAN cache re: portlets.
>
> We can cache a Portlet object that is associated with a portlet instance.
>  A "portlet instance" is one placement of a portlet on a particular
> portal page.  Each portlet instance now has a unique (within a portal
> page) id.
>
> The information from the registry for the portlet (parameters), for the
> portlet and all parents, and the information from the psml (more or
> override parameters) can all be part of the cached Portlet object.
>
> When any of this information changes, due to a re-load of the registry,
> or a customization of the portlet on the page, we must invalidate this
> object from the cache!
>
> Two of the same portlets on the same page need to have different Portal
> objects (these have different peids, at least, and maybe different psml
> parameters).
>
> Two of the same portlets on different portal pages need to have different
> Portal objects as well, for the same reason.
>
> A cached Portlet object could be reused for subsequent page requests, and
> for page requests from other users viewing the same page.  And only this
> - any other use of the portlet would be a different portlet instance and
> need a different Portlet object.
>
> So, a good handle for caching of one of these Portlet objects would be
> the portlet's PEID, plus the portal page's unique id.  The parameters
> don't matter, nor does the ancestry or meta information, nor does the
> portlet class.
>
> I'll start making this change, if I hear a positive sanity check from the
> developers.
>
> Do we have anything from a portal page (or from the root portlet set
> element in a page) that can be used for a unique portal page id?  I need
> it for this (and other purposes!).  The file name is ok, but probably
> won't work for database versions... Do we need to add a new PEID for this
> at the portal level?
> >
> >
> > In fact, isn't the portlet cache totally wrong?  If it finds
> > a portlet object in the cache, and uses this as the portlet
> > object in the portlet set used to process the request, and
> > there's any sort of multiple portlet instances going on (or,
> > for that matter, any other user is viewing another page that
> > has the same portlet!), it will start reusing and modifying
> > meta/id on the object!  I hope this is not the case...


- -- 
David G. Powers
PowerSource

-----BEGIN PGP SIGNATURE-----
Comment: Verify the authenticity of this message with the public key available at http://pssp.com/dgp_pk.asc

iD8DBQE8qRNajmjAPDT0/nERAkeZAKC7CLDZdNfLA7I1B4IJtkrUCn/2uQCfQODD
Jj7yPpkTF29m6gkiBLbT7sQ=
=uDzr
-----END PGP SIGNATURE-----

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message