portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Portlet Caching problem
Date Tue, 02 Apr 2002 18:51:18 GMT
So we've finally discussed something that interests you ;)

> -----Original Message-----
> From: raphael.luta@networks.groupvu.com 
> [mailto:raphael.luta@networks.groupvu.com] 
> Sent: Tuesday, April 02, 2002 5:06 AM
> To: Jetspeed Developers List
> Subject: Re: Portlet Caching problem
> 
> 
> Santiago Gala wrote:
> > raphael.luta@networks.groupvu.com wrote:
> <snip>>>
> >> Caching:
> >> --------
> >> Caching is necessary for 2 reasons:
> >> - avoid expensive convertion cycles from Entry -> PortletConfig
> >>   (PortletFactoryService)
> >>   This can simply be achieved by removing PortletConfig altogether 
> >> and
> >> using
> >>   directly an Entry associated to a Portlet.
> > 
> > 
> > +1 We have suffered enough from PortletConfig already...

+1 I feel the pain. Im prototyping an external portlet-ref feature now.
Going to try an aggregation based off entries and not
PortletConfig/PortletSet.
Let you know how it goes

> > request/session and page/user context information. All request and 
> > session state info should be dealt with using parameters in 
> getContent() 
> > (RunData for request info, Entry for page info)
> > 
> 
> +1.

RunData is an impl detail. We should wrapper it with
PortletRequest/PortletResponse to mirror the servlet api   

Need a better abstraction for entry. Perhaps 'PortletInstance' coming
out of the request



--
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