Jean-Marc Orliaguet wrote:
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

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.

This gets to a terminology problem.  JSR 168 defines portlets to
mean something quite different. In particular, JSR 168 specifies
portlets that are used by end users, by which I mean the final users,
as opposed to content managers, of a site to control what they
personally see on a site. This is what Rob was refering to.
(BTW, we would prefer that the term "portlet" be used to talk
about portlets as defined by JSR 168.)

Your local portlets are used by content managers to define
content to appear in the o-wrap, based on site location.

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.

You still seem to have the desire have portlet assignment apply to a
a folder and to subfolders, with subfolders being able to add
portlet definitions.  As you pointed out in another note, this makes
order control challenging.

You introduce new term "display element", but you don't say enough
about what it does.  I'm happy to let that pass. ;)

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?

I also mentioned that there are several distinct activities that I
think should remain distinct.  In particular, and I think you agreed,
the system we are discussing here should not try to address the content

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

I just don't see perspectives adding anything here.  The application
designer can just as easily use different master pages for different
activities/tasks and assigne different portlets to different slots
in the different master pages.

I see some negatives with perspectives:

- They introduce a need for some complex infrastructure.

- It's not clear what impact they have on URLs.  If, for
  example, perspectives are set via cookies or session
  data, then both bookmarking and caching become more complicated.

- By introducing modes, I worry that they will make it
  harder to talk about and teach systems build with them.


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

Reply via email to