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
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
- 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
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
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
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 Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list