[Zope3-dev] Re: Brainstorming page architecture, pagelets, portlets, etc.

[Jean-Marc Orliaguet]

Janko Hauser wrote:

>Jean-Marc Orliaguet wrote:
>
>  
>
>>On the contrary using the same objects in different layouts makes it
>>possible to reduce memory usage since the content of the cached objects
>>is the same.
>>
>>    
>>
Hi!

>Ah ok, yes, that's an advantage of caching nearly rendered parts. With
>this I mean assembled bits of content, which are already in a structure
>for the last rendering. This would be the approach to have a DOM-like
>tree, where the page is present in some datastructure, which can then be
>transformed into html or some other output format.
>
>Although what I meant was caching in something like squid. Which is
>difficult for all kinds of dynamic sites, but sometimes needed.
>
>  
>

OK then there are two possibilities:
- use ESI (edge-side-includes) to cache portions of a page. Since each 
object has a render() method they can be rendered directly by writing a 
URL with the relative path of the context.
- cache the entire page. Then you need to know if the content of a 
portlet has been modified after the content of the main content area 
which typically is a document. One solution which is being investigated 
is to run a catalog search on all portlets displayed on a given page 
(0.01s) and use the date of of the most recent modification (either when 
the cache was invalidated for that object or when an object was added or 
removed, or moved). Then you can inform SQUID about that date.

The idea is to do caching both in Zope and in Squid and have the cache 
entries in Squid invalidated as soon has the content has changed in 
Zope. The current architecture with page template and slots makes it 
impossible to do that.

>>It is the renderable content of the layout (the leaves) that are cached
>>not the layout itself or the intermediate containers, so it is
>>irrelevent which layout renderer is being used. There can be typically
>>100 objects in a portal that are cached and invalidated independently of
>>the layout / page template. The layout renderer simply aggregates them
>>by looking in the cache.
>>
>>Even the styling is separated from the content and box decorations are
>>added on-the-fly so when you move a box from a part of the layout to
>>another (or from a layout to another) it will get another style (colors,
>>icons) and a new box decoration for the price of a single cache entry.
>>
>>Layouts can be selected by URL, by setting a cookie, by setting a
>>session variable, or by setting attributes locally in folders. But again
>>since the layout is not cached, it is not a problem. I'd like to port
>>all that to Zope3 but I'll first have to learn how it works.
>>
>>    
>>
>Is this the approach taken in CPSSkins? Will have a look at it.
>
>Thanks for your input.
>
>__Janko
>
>  
>

It is the approach used in CPSSkins/CPSPortlets.

regards /JM