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.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to