You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ĎURDINA Michal <mi...@assetsoft.sk> on 2004/12/01 11:25:56 UTC

[portal] Need for CachingPortletAdapter

Hi,
currently provided PortletAdapter does not offer caching ability for JSR168 portlets. I really need caching for portlets and I wanted to implement this feature as new CachingPortletAdapter.

Having looked at URICopletAdapter and CachingURICopletAdapter the caching implmentation for coplets is pretty simple.

CachingURICopletAdapter relies on these principles:
 - coplet content is XML 
 - coplet content it is cached/emited in the generator of portal generating pipeline 
 - links are cached untranslated and the link translation occurs in the transformer that follows generator

PortletAdapter relies on these principles:
 - portlet content is not XML (however it is often XHTML)
 - portlet content is emited in serializer of portal generating pipeline 
 - links are translated in the portlet generation and are part of portlet content

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

Has anyone been thinking about the caching of content for JSR168 portlets? I would be happy if we could come to common solution that could be consequently implemented.

Michal

Re: [portal] Need for CachingPortletAdapter

Posted by Ralph Goers <Ra...@dslextreme.com>.
ĎURDINA Michal wrote:

>Hi,
>currently provided PortletAdapter does not offer caching ability for JSR168 portlets. I really need caching for portlets and I wanted to implement this feature as new CachingPortletAdapter.
>
>Having looked at URICopletAdapter and CachingURICopletAdapter the caching implmentation for coplets is pretty simple.
>
>CachingURICopletAdapter relies on these principles:
> - coplet content is XML 
> - coplet content it is cached/emited in the generator of portal generating pipeline 
> - links are cached untranslated and the link translation occurs in the transformer that follows generator
>
>PortletAdapter relies on these principles:
> - portlet content is not XML (however it is often XHTML)
> - portlet content is emited in serializer of portal generating pipeline 
> - links are translated in the portlet generation and are part of portlet content
>
>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.

>Has anyone been thinking about the caching of content for JSR168 portlets? I would be happy if we could come to common solution that could be consequently implemented.
>  
>
No, I haven't been thinking of it, but it seems like it would be a good 
thing. I'd welcome a proposal and/or code.

>Michal
>  
>
Ralph