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:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 4:50 PM To: [email protected] 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
