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

[Jim Fulton]

Jean-Marc Orliaguet wrote:
> Jim Fulton wrote:

...

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

Why is this a disadvantage?

> - difficult import / export

I don't follow this.  Do you mean that you'd like to export/import portlet
assignments independent of everything else?

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

In that case, I don't understand why what you have now is inadequate.
Now, users define a portlet in exactly one part of a site (and all subfolders).
What am I missing?

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

You mean you want users to select different collections of portlets for
different activities?  If so, then why not just use different master pages
and slots for the different activities?

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

Perspectives are about providing separate task-oriented UIs.
A perspective is about performing a particular type of task on
input.  In many ways, it's like the Zope 3 view/adapter model,
where we have different views selected by input and by type,
where type expresses the kinds of tasks performed.  It is not
simply an arbitrary grouping of components.

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

I don't understand your answer.  1. I don't know what you mean by
"these portlets". Do you mean in the current (undesireable) solution
or in the new solution.  It seems the statement applies to both.
2) I don't understand why being associated with different activities
or targeted to different target audiences is undersireable.

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

> this is a minor problem actually and I've changed my mind on this issue
> since last week,

I still don't know which pages you were talking about so I don't know
what you changed your mind about. :)

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