cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DURDINA Michal" <michal.durd...@assetsoft.sk>
Subject RE: ANN: [portal] New CachingPortletAdapter
Date Fri, 07 Jan 2005 16:33:44 GMT
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:cziegeler@apache.org]
> Sent: Friday, January 07, 2005 1:14 PM
> To: dev@cocoon.apache.org
> 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:Ralph.Goers@dslextreme.com]
> >>Sent: Wednesday, December 08, 2004 4:50 PM
> >>To: dev@cocoon.apache.org
> >>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
> >>>
> >>
> >>
> > 
> > 
> 
> 

Mime
View raw message