[Zope3-dev] [DRAFT] local portlets and perspectives

[Jim Fulton]

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

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

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

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

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org