Sorry for just a quick response. JSR168 - portlet specification really defines something like "expiration cache", which when set to -1 should provide caching of portlet content.
But as I see it: * according to spec, implementation of caching is optional for portlet container * content would be cached also with translated links (conflict with DefaultEventConverter - that generates links only with one request validity) * portal samples already contains <expiration-cache>-1</expiration-cache> but caching is not working (try to output current time in TestPortlet - it will always refresh) * yet must investigate pluto distribution wheter caching is supported by pluto container at all Michal > -----Original Message----- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Friday, January 07, 2005 1:14 PM > To: [email protected] > Subject: Re: ANN: [portal] New CachingPortletAdapter > > > Hi, > > the portlet standard already supports caching; each portlet can be > configured to be cached and the portlet container (in our case pluto) > should cache the content. > So I think our portal already does the caching. Or do I > oversee something? > > Carsten > > DURDINA Michal wrote: > > Hi, > > after some days of coding I finished the implementation of > CachingPortletAdapter ! With CachingPortletAdapter you can > have JSR168 portlets that behave (almost) exactly as they > were every opened in single web browsers. This means that > only one portlet that triggered the action is regenerated at > the time. Content of other portlets are returned from cache. > Porlet content caching was also possible using non-caching > PortletAdapter, but developers needed to implement caching > behaviour inside their portlets. Moreover changing portlet > window state (maximize/minimize/normalize) can be now > optionally handled just by portal without calling the > portlet. This code is already in our application and is > already tested. > > > > CachingPortletAdapter works on these principles: > > * portlet hyperlinks are cached with contents > > * links for window icons have different validity category > mode that links located in content > > * fullscreen state stored on session > > > > Some extensions to existing implementation was required: > > * added links validity categories to EventConverter > (request, half-session, session, permanent) > > * new CopletLinkingEventConverter that implements > half-session links validity > > * new PortletInstanceEvent implemented by > PortletURLProviderImpl to distinguish that portlet events are > NOT targeted to CachingURICopletAdapter (caused conflict) > > * storing EntryLayout (fullscreen) to PortalService > attribute (session) instead of temporaryAttribute (request) > > * refactoring of caching methods to new CopletCache class > > * refactoring of portlet content loading to > loadPortletContent method > > * all changes are backwards compatible > > > > CachingPortletAdapter in hierarchy of coplet adapters: > > AbstractCopletAdapter > > PortletAdapter URICopletAdapter > > CachingPortletAdapter CachingURICopletAdapter > > ApplicationCopletAdapter > > > > The code is submitted in bugzilla: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=32991 > > > > The code contains modified samples that demonstrate new > portlet caching ability. It has been tested with > cocoon-2.1.6. Please take a look at it and possibly apply it > to BRANCH_2_1_X and thereafter to trunk. > > > > Thank you, > > Michal > > > > > >>-----Original Message----- > >>From: Ralph Goers [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, December 08, 2004 4:50 PM > >>To: [email protected] > >>Subject: RE: [portal] Need for CachingPortletAdapter > >> > >> > >>Michal, > >> > >>Unfortunately, I have a lot on my plate right now. I'm going > >>to have to do > >>some research to look into your proposals below and so I > >>won't be able to > >>give you my opinion for a few days. But I don't want you to > think I am > >>ignoring this. > >> > >>Ralph > >> > >> > >>�URDINA Michal said: > >> > >>>Hi, > >>>I got finally into PageLabels that are implemented in > >> > >>portal block in > >> > >>>cocoon 2.1.6 and documented at > >>>http://wiki.apache.org/cocoon/PortalPageLabels. > >>> > >>>Ralf Goers wrote on > >>> > >> > >>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=11019115492 > 5434&w=2: > >> > >>>>>Main issue I see in implementing CachingPortletAdapter is > >>>> > >>>>"link translation". > >>>> > >>>>>1.) links that are sent to browser are valid only for the > >>>> > >>>>next request > >>>> > >>>>>2.) translated links are part of generated content > >>>>>3.) portlet content cannot be cached since its links will > >>>> > >>>>not be valid after next request > >>>> > >>>>> > >>>>If you use PageLabels the above is not true. Events are > >> > >>valid until > >> > >>>>they are regenerated on the next request to that page label. > >>> > >>>It is not exactly so. Lifecycle of links when using > >> > >>PageLabels is very > >> > >>>simmilar to that in the original DefaultEventConverter. They are > >>>genereated and stored to ENCODE hashmap in the coplet > >> > >>generation phase and > >> > >>>live until the portal tab page is generated again. Links > >> > >>are preserved > >> > >>>ONLY when switching form one tagged page to another tagged page. > >>> > >>>Therefore I refine my statements of issues for implementing > >>>CachingPortletAdapter (using PageLabels): > >>>1.) links that are sent to browser are valid only for the > >> > >>next request > >> > >>>(unless the tagged page is switched) > >>>2.) translated links are part of generated content > >>>3.) portlet content cannot be cached since its links will > >> > >>not be valid > >> > >>>after next request to the same tagged page > >>> > >>>I have CachingPortletAdapter finished, but I must solve the > >> > >>problem with > >> > >>>links to make it working. > >>> > >>>I see these possibilities: > >>>A.) invert the responsibility and let the coplets to > >> > >>maintain lifecycle of > >> > >>>their events/links > >>> > >>> - coplet will add the event to store (EventConverter) on content > >>>generation > >>> - coplet will remember its own list of its events > >>> - coplet will remove its remembered old events from the store when > >>>regenerating or removing (logout) > >>> - EventConverter will not remove events > >>> > >>>B.) enhance PageLabelEventConverter and add name of coplet > >> > >>instance to key > >> > >>>for events store > >>> > >>> - currently only page tab name is used for pageLabel > parameter i.e. > >>>portal?pageLabel=Gallery&cocoon-portal-event=3 > >>> - after adding coplet instance name the link would look like this > >>>portal?pageLabel=Gallery.Gallery-Viewer&cocoon-portal-event=3 > >>> - new events for one coplet now don't replace old events > >> > >>for another > >> > >>>coplet on the same page > >>> > >>>C.) add compare method to event interface > >>> - before new event is stored to events store compare new > >> > >>event with old > >> > >>>events whether "same" event not already present in the store > >>> - if same event is found between old events it will be > >> > >>returned instead > >> > >>>of new on and the link will stay the same (index to store does not > >>>change) > >>> - gradually all links from portal are stored in the events > >> > >>store but > >> > >>>there is no duplicate and the indexes to events are > >> > >>preserved between > >> > >>>requests > >>> > >>>D.) name one :) > >>> > >>>I find the > >>>case A.) is little bit harder to implement but it was my > >> > >>first thought :-) > >> > >>>case B.) is nice and clean way how to prevent that events > for cached > >>>portlet without focus will not be overriden by currently > >> > >>focused coplet > >> > >>>case C.) is only one that also allows the browser back > >> > >>button to work > >> > >>>properly because repeated http requests will invoke same > >> > >>action as the > >> > >>>event will be still alive in the store. Of course, internal > >> > >>coplet states > >> > >>>are not taken into account. This simplified view solves > >> > >>only situation > >> > >>>when coplet state is maintained exclusivelly through > >> > >>request parameters. > >> > >>>I would like to know, if anyone has any preference to one or other > >>>solution. Also all cases can have some issues that am not > >> > >>aware of and I > >> > >>>would be happy if you could also point them out. > >>> > >>>Thank you, > >>>Michal > >>> > >> > >> > > > > > >
