Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
>> Somehow related to the discussion on optimizing catalog queries, I have
>> been thinking about how to best implement local portlets in cpsskins in
>> terms of scalability, performance and functionality. The implementation
>> is heavily dependent on being able to performance effective catalog
>> queries (it is OK to wait 2 seconds in an ECMS to search 1 million
>> documents, but it is not OK to have to wait 2 seconds to render a page
>> containing portlets).
>> Here is the proposal:
>> It is built on the notion of "Perspective" (see the link) and on the
>> idea of querying the catalog using triadic relations instead of joining
>> sets of query results based on dyadic predicates (such as with RDF).
> I'd like to make some substantive comments on the proposal. My initial
> reaction is that the solution proposed is very complex and I'm not at all
> clear about the problem it solves. :)
> I think I need to understand how themes work in CPS skins. In
> I need to understand the relationships between themes, pages, sections,
> cells, global portlets and local portlets. Your proposal is based on
> but doesn't really describe most of these concepts. Can you recommnd
> some documentation?
Hi Jim, here are the concepts defined:
- A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you
see that sites are using different themes. The includes, colors, styles,
- Inside a same theme there are *pages*, pages use the styles defined in
the theme, but the layout may be different (3 columns -> 2 columns) from
one page to another. The rationale is that when you create a new page,
you want to be able to reuse the same styles.
typically there is: the front page, the section page, the login page ...
- a *section* of a site is not specific to cpsskins, it can be a folder,
a project room, a workspace, cnn.com has "World", "U.S", "Weather", etc.
- *cells* are layout elements in a page that could be also called
"columns", the left column can contain navigation portlets, the right
column can contain ads, the main column usually the document being
- *global portlets* are part of a page, they are placed in cells. i.e.
if a page is displayed and the portlet is in the page, then the portlet
will be displayed. Typically global portlets are: the logotype, some
navigation portlet. Only theme designers can manage global portlets.
They make the theme's skeleton.
- *slots* are placeholders that can contain portlets. A theme designer
will add slots to a theme, but it's not up to him/her to define which
portlets will be displayed in the slot. The theme design will decide
what style the portlets inside the slots will have.
- local portlets are placed in slots by the users themselves.
here is an illustration:
on the chalmers website here is the front page:
here is the same page with the slots, global portlets and local portlets
- global portlets are represented in orange, no user that is not theme
designer is allowed to modify them
- the slots are represented by areas with a red border.
- the local portlets are represented in violet. users who work with
content can modify them and add new ones into the slots.
here the template uses with Chalmers institutions:
content creators can only add content inside the predefined slots, which
guarantees that the graphic profile is preserved.
What problem perspectives solves?
local portlets are currently stored in local folders in a .cps_portlets
container with the name of the slot in which they are located.
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. 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.
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
In an application, this makes it possible to keep the portlets used by
the application (action portlets, navigation portlets) separate from
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
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.
Zope3-dev mailing list