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

[Jean-Marc Orliaguet]

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
> ...
>
>> What problem perspectives solves?
>> ------------------------------------------------------
>
>
> I think I'm ready to respond to this now. I hope, with your current
> thinking that this is still relevent.
>
good :-)

>> local portlets are currently stored in local folders in a .cps_portlets
>> container with the name of the slot in which they are located.
>
>
> So, .cps_portlets is a container with an item for each slot, which, is,
> itself a container?  Then users add items to this container to add
> portlets?

that's the Zope2 implementation of local portlets. It has advantages:

- the role for managing portlets is the same as the role for managing
content in a folder
- portlets are visible starting from the folder in which they are stored
physically.

the drawbacks:

- portlets get scattered all over the site, there is no unity.
- it is not possible to create a portlet set without first creating the
folder in which they'll reside
- users must have permission to write in the container to add folders,
hence they must have access to the folder
- difficult import / export
- a traversal is needed from the current folder to the root of the site
to determine which portlets will be displayed
- portlet ordering is a pain since there is no unique set of portlet.

>
>> It means that the user has to go into a given folder, add a portlet into
>> a slot and the portlet will be visible starting from this folder. After
>> a while there are 100 of portlets scattered around the entire site, some
>> in /sections/A, some in /sections/A/B some in / ...
>>
>> there is no grouping of portlets.
>>
>> we find out that what users actually want to do is to define a set of
>> portlets that will be shown in a given section of the site (eg. in
>> 'education', in 'research', ...) and only there.
>
>
> Meaning not in subfolders?


probably in subfolders too, depending on where the perspective will be
used (most certainly starting from a given section of a site, until it
is overridden by another perspective) -- this is a separate issue
though, since a perspective is not tied to a given folder, object type
when it is defined..

>
> > This is somehow done
>
>> when portlets are stored in folders, but it is very difficult to group
>> the portlets together, because there is no notion of "group of portlets"
>> displayed in given context.
>
>
> I don't know what you mean by "grouping portlets", or why it is a good
> thing.
>
I mean creating sets of portlets: the set of portlets used in a blog, in
a calendar, in a section of a site and being able to treat them as a
group. This is for the same reason that user folders have groups of users.

>> so basically the notion of perspective is just a way of grouping
>> portlets together and give a name to that collection, so that a user can
>> decide: when I'm in this section of the site, I want to show this set of
>> portlets.
>
>
> This doesn't seem consistent with your current notion of perspectives.


in what sense? again there are two separate notions:
- the notion of perspective
- the notion of applying a given perspective to a given context.

>
>> In an application, this makes it possible to keep the portlets used by
>> the application (action portlets, navigation portlets) separate from
>> decoration portlets.
>
>
> I'n not sure what you mean.  By "application", do you mean the content
> management application, as opposed to the end-user content-delivery
> application?
>
I mean a webmail application, a calendar application, a web publishing
application.
Currently the portlets used in a CMF site for instance are of two kinds:
1) portlets that are used by the web publishing application (workflow
actions), login link...
2) portlets that show content (latest news, info text, ...)

the site visitors are usually not interested in 1)

>> currently we manage the separation by using different themes (one for
>> the external site, and one for the "back office"), the slots names are
>> different, so the portlets in the backoffice on not visible on the
>> external site.
>
>
> And how is this solution undersireable?


these portlets are associated to different activities and they are
usually meant to be seen by different target audiences.

>
>> Also we have problem when a same slot is present in many pages, the
>> users think that they are add portlets only on a given page, while they
>> end up also being visible in other pages.
>
>
> I'm not sure what you mean by page here.  Do you mean theme/master pages
> or web pages?
>
> Jim
>
this is a minor problem actually and I've changed my mind on this issue
since last week, I think that slots should be identified by their name
that can be shared between slots located on different pages and not by
an id that is unique per slot, to make it possible for an application
designer to specify the slot in which portlets should be shown ('left',
'right', ...) as it is done with CMFDefault.

I have written a doctest that explains this:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/local-portlets.txt

/JM