Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > ... > >> 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?
Yes, I think that Rob mentionned that there was such a use case where you had customers who wanted to control the way portlets were disposed on the screen on an individual basis. Generally speaking, portlets are associated to slots but the ordering information is neither stored in the portlet itself nor in the slot, but in a "display element". There are as many display elements associated to a given slot as there are perspectives. In this way visual ordering is not a problem, and it should also be possible to place the portlets inside the slot's display canvas on using (x, y) coordinates. I don't know about a use case for this unless maybe in the content well, I think you mentionned something about this in a previous mail? > > > all that is > >> needed is a portal page with three slots in it.... > > > Why is the number of slots important? > > ... It's not --- it was an example, it is the number of slots used in google's news portal ... > >> 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. I'm going to put a diagram online showing what they add in terms of separating responsability in the design of a web application, web sites, ... The idea is that the three roles: - theme designer (creates themes, styles, etc...) - programmer (creates portlets, special views for some object types, ...) - application / UI designer (puts all the pieces together) are completely orthogonal. With this you can ask a group of graphic designers to work on some graphic designer for an application, or a site. They'll be able to work on their own without interfering with programmers. They'll create a couple of master pages, they'll place slots inside the pages. This is where their responsibility ends. simultaneously you can ask a group of programmers to create portlets (page fragments) that define the functionality of the site / application. then the application designers, UI designers, website content creators are able to put everything together be creating perspectives. They'll be able to do this before the site with all its content (folder, etc...) even exists. Bottom line: there is a very clear separation of roles. You can't do this today, because the roles are too intertwined. /JM _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
