portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Portlet Caching problem
Date Tue, 02 Apr 2002 23:21:15 GMT
David Sean Taylor wrote:

>
>>-----Original Message-----
>>From: Glenn Golden [mailto:ggolden@umich.edu] 
>>Sent: Tuesday, April 02, 2002 12:46 PM
>>To: 'Jetspeed Developers List'
>>Subject: RE: Portlet Caching problem
>>
>>
>>For RSS portlets, perhaps we can introduce a jetspeed RSS 
>>service.  This would take care of fetching / caching the rss 
>>document, and perhaps provide translation to html service (if 
>>this is startup intensize and would benefit from some shared 
>>persistence).
>>
I was just thinking exactly the same. A service could deal with content 
generation and caching of RSS channels with different parameters (number 
of items, mimetype, ...). Then the portlet would just check the request 
parameters and ask for a fragment. Those fragments would be shared 
implicitly.

>
>-1 
>I like the way RSS portlets work now. 
>Perhaps its just what Im used to, but the configuration is minimal and I
>like configuring per portlet.
>Some people (like me) actually use these silly portlet things!
>
I'm also -1, because I think we can focus into more important things.

I prefer if we follow Raphael's suggestion that we get rid of 
PortletConfig inside Portlets and we separate rendering API (portlet) 
and Profile/PSML API. We would use Entry for getContent() calls to give 
context to the Portlets, instead of having a setConfig() call before a 
getContent() call as we do have now. This is rather messy, and has 
costed us already a lot in terms of race conditions and concurrency issues.

>
>Prefer breaking the AbstractPortlet into several AbstractPortlets as we
>discussed before
>

Now we have:

- "plain" portlets
- Portlets that implement Cacheable (although Cacheable is deprecated, 
we use it, and this is why there is a CacheablePortletWrapper and a 
CacheableStatefulPortletWrapper)
- Portlets that implement PortletState (allow/get/set Closed, Maximize, 
Minimize, Customize (only allow) )
- we had Portlets that implemented PortletCustomizer. Glenn has patched 
them by adding a method to the Portlet interface.

One of the reasons why we have such a mess of interfaces is because we 
were careful to keep API consistency.

I think Cacheable could be a candidate to disappear, being substituted 
by direct use of an object cache by the Portlets needing it (RSS comes 
to mind ).

>
>Btw - is there truth in the rumour that in some countries a 'portlet' is
>a portable toilet? 
>
Not in mine :)


--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message