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

[Jean-Marc Orliaguet]

Jim Fulton wrote:

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


no, they are used by end-users as well -- this is already the case in
the Zope2 version of cpsskins -- inside the perspective that they have
permission to work in.

this is where I don't understand how you can with a view / adapter /
page template paradigm get the JSR 168 portlets to fit in. Views,
adapters are for programmers, not for end-users, not even for content
creators.

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


this is the required element that makes portlets ordering not
challenging anymore. But this is another issue..

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


it depends on what the content well looks likes, if the content well
consists of 6 portlets, side by side or one below the other, then this
is not a problem to let the cpsskins layout mechanism take care of that.
I'm still not sure about what you put inside the content well, this is why.

if the content well contains a document with some advanced layout and a
lot of widgets then this is outside the scope of the cpsskins layout
renderer.

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

this is what we do already.. but this is clumsy. Because it forces us to
design a new page just for some portlets that should be hidden.
Maintaining a page, with the styles, layouts, etc takes more time than
maintaining a perspective that only consists of a list of portlets
assigned to some slots.

> I see some negatives with perspectives:
>
> - They introduce a need for some complex infrastructure.
>
what do you mean by "complex"? have you seen the prototype? for a user
it does not seem too complex:

- choose a perspective
- add portlets to it
- assign the perspective to some context

> - 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.
>
what about skins?

> - By introducing modes, I worry that they will make it
>   harder to talk about and teach systems build with them.
>
> Jim
>
what should we say about skins then? they introduce exactly the same
"problems". However they exist in Zope3.

a perspective is a skin but for the portlets in a page. If you think
that perspectives are too complex then the skins mechanism should be
reconsidered...

/JM