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
