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

Jean-Marc Orliaguet jmo at ita.chalmers.se
Wed Nov 10 12:38:14 EST 2004


> Subject: [Zope3-dev] Brainstorming page architecture, pagelets, 
> portlets,    etc.
> Date: Mon, 08 Nov 2004 13:25:53 -0500
> From: Jim Fulton <jim at zope.com>
> Reply-To: jim at zope.com
> Organization: Zope Corporation
> To: zope3-dev at zope.org
>
>
> I've created a wiki page:
>
>   http://dev.zope.org/Zope3/PageArchitecture
>
> to brainstorm ideas for supporting page contruction.
>
> At this point, I think we are mainly defining the problems we are
> trying to solve, terminology, etc., even though there are already
> some implementations, one of which has recently been checked in. :)
>
> Comments, questions, suggestions, contributions, etc. welcome.
>
> Jim
>

Hi all!

spontaneously (from my experience with CPSSkins / CPSPortlets) I would 
suggest the following:
- have a product that generates a skeleton site layout with a generic 
interface for rendering portlets, pagelets, etc to let third-party 
products provide their own objects to render.
- use python methods to do the rendering (e.g. object.render() ) - it 
makes it possible to cache content easily.
- get rid of ZPT macro slots alltogether for the site layout (they are 
cumbersome, not modular enough and I still see no generic way of caching 
the content of a slot)
- implement a pluggable caching mechanism to let third party products 
inform when the content (portlets, etc,) has expired, it is not the 
layout generator that should decide when to invalidate cached objects. 
let the cache mechanism be as generic as possible (event-driven, cache 
timeout, ...)
- maybe have a user interface that supports drag-and-drop that 
third-party products can use out-of the box.
- have a modular architecture so that pagelets can contain portlets, 
etc.. or pagelets can contain pagelets, etc but without specifying too 
much. i.e. mostly have a container that recursively renders all objects 
in the container until this is nothing left to render.
- have several layout generators ( a bit like in uPortal ) for different 
devices (PDA, web, print,  etc..)
- for the styling, have a pluggable interface to let the layout renderer 
write CSS class names and let portlets, pagelet register their own CSS 
styles (that should be done through a renderCSS() method, not through a 
flat CSS document)
- for javascript also use a pluggable interface to avoid having a huge 
Javascript documents loaded on each page.

basically have a page renderer that is as pluggable as possible with a 
common interface for CSS styling/Javascript/drag-and-drop, etc. so that 
third-party products can provide with the content independently of the 
layout.

I am not too familiar with the Zope-3 architecture though.
regards /JM



More information about the Zope3-dev mailing list