ANN: [portal] New CachingPortletAdapter

[DURDINA Michal <mi...@assetsoft.sk>]

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=110191154925434&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
> >
> 
> 

Re: ANN: [portal] New CachingPortletAdapter

[Carsten Ziegeler <cz...@apache.org>]

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=110191154925434&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
>>>
>>
>>
> 
>