[Zope3-dev] [DRAFT] local portlets and perspectives

[Jim Fulton]

Jean-Marc Orliaguet wrote:
...
> Concerning unification:
> During the sprint in Göteborg in June  according to what Tres mentionned
> it appeared to me said that the issue was to make portlets independent
> of any macro mechanism, and that the they should be treated as page
> fragments without any assumption about where on the page or inside which
> template they'll be displayed.

I would agree that, generally, page fragment will/should generally
be designed independently.  We certainly have use cases for being
able to explicitly assember page fragments to create pages.  This is
typically for the "content well".  To be more accurate, we often
compose pages by assembling views of content such that the views are
designed to be page fragments.

> the idea was to chop the page into pieces and reuse the pieces.
> 
> the rendering engine in cpsskins is designed to do layouting/styling of
> the "O wrap" area in the way that *web designers* are used to work with.

Yup.

> By using "perspectives" end-users can also use the portlet editor to
> move portlets on the canvas (as in the google news portal),

By end-users, do you mean content managers? Or end-users of the
content?

Why do they need perspectives to do this?

Do you envision them being able to control the order of
the portlets?

 > all that is
> needed is a portal page with three slots in it....

Why is the number of slots important?

...

> This is what I meant with having a "unifying concept". And that sounds
> very unifying to me already.

Perspectives, if I understand how you are describing them, and how
Eclipse describes them,
http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,
are simple separate applications.  They are different ways of working on content
based on tasks.  They could be provided with perspectives, or, more simply,
with different collections of web pages, using different styles.  I
don't understand the benefit you think they provide nor do I see how
they unify anything.

> But when it comes to the content well, I strongly think that the
> layouting is best delegated to other rendering engines, XForms, for
> instance (Julien could tell you more about it), iCal renderers, Flash
> plugins, etc.. Otherwise you will lose the generic aspect of cpsskins,
> and the layout engine will become extremely complicated to manage. I
> think that the content well should in that case be *one* portlet that
> knows how to do its own layouting and not be a mixture of portlets.

I think we are in agreement here. :)

> rendering a weekly calendar view would otherwise be a real pain if the
> meetings booked were portlets...
> 
> In CPSSkins for Zope2 for instance it is still CPSDocument that creates
> the layout of documents and it is best done that way I think.

Yup.

> have a nice week-end!

Thanks. I did. :)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org