cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers" <Ralph.Go...@dslextreme.com>
Subject RE: [portal] Need for CachingPortletAdapter
Date Wed, 08 Dec 2004 15:50:28 GMT
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
>


Mime
View raw message