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 >
