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.


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

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


have a nice week-end!

Thanks. I did. :)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to