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