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: Portlet Caching problem - PER SESSION
Date Tue, 02 Apr 2002 05:00:41 GMT

The WebPageProxyPortlet sounds great.
Look forward to it!

> -----Original Message-----
> From: David G. Powers [mailto:jetspeed-dev@pssp.com] 
> Sent: Monday, April 01, 2002 6:12 PM
> To: Jetspeed Developers List
> Subject: Re: Portlet Caching problem - PER SESSION
> 
> 
> -----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>
> 
> 



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