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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
