ZopeMag's mascot the ZOPE fish


Article Finder
People
Issue 9 - Revision 8  /   February 7, 2005 


 
  ZopeMag Links:
Latest Issue
About the Fish
Issue 10
Issue 09
Issue 08
Issue 07
Issue 06
Issue 05
Issue 04
Issue 03
Issue 02
Issue 01
 
 
Downloads
     
  Letter from the Editor:


Interviews:
Each issue we interview important people in the Zope world.

  Joel Burton

Articles:
Throughout the quarter we cover topics of interest to Zope developers, designers, and users.

  Improving WebDAV in Zope

  Profiling Zope (Part II)

  Redesigning the portal with CPSSkins and CPSPortlets

  Zope and Flash

  Localization (Part I of II)

Product Review:
Too many Products, too little time? ZopeMag keeps you up-to-date which Zope Products are worthwhile checking out.

  Corp Calender
  BastionLedger


Book Review:
Thanks to a growing subscriber base we can now offer even more to our readers. Zope and Plone Book Reviews!

  The Definitive Guide to Plone


Guides:
This quarter we bring you a new SuperGuide. Our miniGuides and SuperGuides give you the background knowledge you need to mastering Zope.

  miniGuide to writing Zope 2 Products
 
 
Downloads
     
  URLs / Download
Products we talk about in this issues Articles and Reviews

     


Redesigning a portal with CPSSkins and CPSPortlets.

- - - - - - - - - - - -

By Jean-Marc Orliaguet  | October 29, 2004

print

Introduction

CPSSkins is a product developed at Chalmers University of Technology for the Collaborative Portal Server (CPS) which allows designers to control the layout and the appearance of their site. CPSPortlets, developed in collaboration with Nuxeo, makes it possible to insert portal components (also known as "portlets") inside the CPSSkins layout. Both CPSSkins and CPSPortlets are compatible with CMF and Plone.

Designing a portal

Running a portal is a difficult task. It involves getting graphic designers, content creators, ad writers and site managers, to work together so as to produce a homogeneous visual experience for the end-user. Roles and responsibilities must be well-defined and new roles often need to be created.

A classical approach in portal design consists of implementing a predefined site layout throughout the portal. Users are allowed to create and publish documents but they have no direct control over the portal content around the main content area. Content creators may, for example, need to publish image ads directly on the front page of the portal or select, inside given areas of the portal, an alternative site layout which is more adapted to certain types of documents.

It is clear that this approach puts a lot of responsibility in the hands of a few who have the technical expertise required to perform modifications on the portal. As a result, in large organizations site managers can easily become "bottlenecks". In such situations the only viable solution may consist in delegating the site manager role to users that at the outset were only supposed to be working on producing content.

But this is not the best way to delegate responsibility since as few users as possible ought to have the manager role. Delegating responsibility implies moving from a centrally managed portal to a portal where users are given more responsibilities but within certain limits. The goal is to define those limits.

To achieve this end, CPSSkins and CPSPortlets implement the notions of global and local objects - that is, global and local themes in the case of CPSSkins and global and local portlets in the case of CPSPortlets.

Global objects are available throughout the portal. They are created by site managers in order to define the domain areas inside which users will have the freedom to create content. Such global objects are, for example, a collection of site layouts, or a list of slots inside which users will be able to insert portlets.

Local objects such as local themes or portlets are created by users inside the folders that they have control over - that is, in personal folders or in workspaces. Local content is managed by the principle of delegation of roles inside folder structures.

It is the combination of these two notions that give users more control over the portal. This article describes the steps to follow in designing such a portal.

Designing a basic layout

A site layout often used on Websites is the C-shaped layout. It consists of a header, a left column with navigation items, a main content area displaying documents and a footer with some contact information. Optionally, a right column containing dynamic information (latest news, upcoming events, etc) can be removed to leave more space for the main content area.

Figure 1 - Example of a site layout


In CPSSkins the page layout is divided up into horizontal blocks called “page blocks” stacked on top of one another. A page block can contain one or several columns. Hence, to create a new layout the theme designer will go into the “layout” mode, define the number of page blocks to use inside the page, divide each block into several columns and set a width for each column. This is done by directly entering the different values in the CPSSkins layout editor.

Figure 2 - The CPSSkins layout editor. The image represents a page block with 4 columns.


Advanced layouts

It is also possible to create more advanced layouts by inserting “cell blocks” into existing cells. In this way a column can be split up into several cells.

Figure 3 - A site layout created with page and cell blocks


Once the main site layout has been created the user interface elements --- called “Templets” --- can be inserted into the canvas.

Adding Templets

Templets are user interface elements that are positioned inside the layout. They can be ordered vertically and they can be moved between different cells. CPSSkins has a set of predefined Templets - for example, the search box, the text box, the portal box, the calendar box, etc.

Every element placed on the canvas of a theme will be visible whenever the theme is being used. Templets are therefore configured by theme designers once and for all, and only portal managers or theme managers may add, remove or modify these types of portal elements. Theme managers may also create special kinds of portlets (called "global portlets") that are visible within the entire portal and that cannot be modified by users.

At this stage, users will be able to interact with the portal but they will not be able to add personal portlet boxes. The next step is then to define the areas inside which users will be able to insert portlets. These areas are called “slots”.

Adding slots

A slot is an empty area on the canvas that has a label.

Figure 4 - Box slots are areas portlets can be inserted into.


Figure 4 shows a site layout with three slots labeled 'left slot', 'image ads', and 'banner'. The 'banner' slot is used three times in this example. This means that whenever a portlet is associated with this slot, the portlet box will be displayed in each of these slots (i.e., three times) identically.

Slots can contain many portlets but there is no way of knowing in advance how many portlet boxes a slot will contain. However, it is possible to define for each slot the appearance and the layout of its boxes. This is done by styling the elements of the portal.

Styling the elements of the portal

Each element of the interface can have its own style. In fact, several styles can be combined together and be associated with page blocks, with Templets and with slots. Styles are classified into categories such as area colors, area shapes, font colors, font shapes, box colors, input form styles, etc.

The same style can be assigned to different portal elements. It is also possible not to associate any style with a given element and have it inherit the style of its container instead. An important idea here is to keep the total number of styles as low as possible.

Apart from styles, portlet boxes can be assigned a layout which describes how the box will be decorated. Boxes may, for instance, have a close button, a minimize/maximize button, they may have no title, etc.

Box styles and box layouts are not applied to individual boxes but to entire slots instead. It is up to the theme designer to decide which style to apply to a given slot, the goal being to allow users to insert boxes into the layout without compromising the overall design of the site.

Inserting portlets

Local portlets are managed by users inside the folders that they own and in the folders inside which they have the “portlet manager” role. To add portlets, users can click on the “manage portlets” option. This opens the Portlets management screen, enabling one to use the contextual menu to create portlets inside existing slots (see Figure 5 below).

The language portlet allows the user to switch between languages and to create versions of the current document in other languages.

  • The content portlet displays the results of catalog searches (latest news, pending documents, upcoming events, etc.).
  • The navigation portlet shows navigation menus.
  • The content creation portlet allows the creation of items inside the current folder
  • The internal links portlet allows the creation of a list of links referring to other documents inside the portal.
  • The text portlet allows the user to create and display a text using a rich-text editor.
  • The image portlet displays an image.
  • The dummy portlet is used for test purposes.
  • The search portlet is a search interface for finding documents inside the portal.
  • The document portlet displays the current document. It is also used to select document layouts when several layouts are available.
  • The breadcrumbs portlet shows a navigation trail.
  • The actions portlet displays portal actions.
  • The language portlet allows the user to switch between languages and to create versions of the current document in other languages.
Figure 5 - Portlets are inserted into slots using the contextual menu


Managing portlets

Once portlets have been created, they can be moved from one slot to another. They can also be reordered inside the same slot. These operations can be performed directly on the canvas, or indirectly via the portlet management screen which is a representation of the actual canvas in a smaller scale. It is also possible to move portlet boxes between the canvas and the canvas representation.

Figure 6 - Portlets are inserted into slots using the contextual menu


Visibility range

By default, the portlets located in a given folder are visible in all sub-folders. But it is possible to set a visibility range for portlets to limit their visibility. In this case they will be visible to a given depth relative to the current folder - for example, starting from a depth level of 2 and going up to depth level of 5. The user interface for managing visibility ranges is not available yet, but the implementation has been carried out in the API.

Time-limited visibility

Portlets may be visible starting from a given date. They may also be set to expire after a given date. The implementation relies on Dublin Core meta-data. The actual user interface for managing time-limited visibility has not been implemented yet.

Translating portlets

All portlets are derived from the CPSDocument class. Hence, they can be made available in many languages. The user interface for translating portlets has not yet been implemented.

Managing local themes

CPSSkins supports local themes. Local themes are themes that are assigned to certain folders and that are inherited through acquisition. By default they are visible in all sub-folders but it is possible to restrict their visibility to certain levels relative to the folder they have been associated with. In Figure 7 the theme associated with the top folder will effectively be used in all level 1 and 2 sub-folders.

Figure 7 - Local themes can be made visible over a given sub-folder depth interval


Stacked themes

Several themes can be combined together and associated with the same folder but differentiated on sub-levels. For example, a given theme may be used for all folders of level 1 while another theme may be used for all folders of level 2.

Figure 8 - Local themes can be associated with folders and with their sub-folders


User interface

Local themes can be managed by users inside personal folders or workspaces. The local theme management screen is accessible via the “Manage local themes” option. It displays the list of themes associated with the current folder.

Figure 9 - Local themes can be associated with folders and with their sub-folders


New themes can be selected and added on top of the stack by using the theme selector. This opens a pop-up window with a list of available themes. To make it easier for users it is possible to use thumbnail images. For example, in Figure 9 the available themes are represented using the features that best characterize them (the color and the layout), but it is also possible to use screen-shots.

Figure 10 - The theme selector displays thumbnail images of all available themes


Advanced usage

The information about local themes is stored as a folder attribute:

  • as the property of a folder; or
  • as an object (e.g. a Python script) located inside the folder which returns a tuple.

The format for describing local themes is:

  • a string containing the theme's id; or
  • 'n-m:theme'

where:

  • 'theme' is the theme's id
  • (n, m) is a pair with n <= m that describes the interval within which the theme will be used.

(0, 0) means the current folder and all sub-folders,
(1, 0) means all sub-folders below the current folder
(1, 1) means the sub-folders of level 1
(0, 1) means the current folder and the sub-folders of level 1
(n, n) means the sub-folders of level n (with n>0)

For example, the following list of themes:

1-1:chalmers-2-blue
2-0:chalmers-3-blue

can be associated with the sections called 'sections/123' by adding a '.cpsskins_theme' property:

Figure 11 - cpsskins_theme property associated with a folder


The property will be interpreted as:

  • theme chalmers-2-blue: visible in sub-folders of level 1
  • theme chalmers-3-blue: visible starting from the sub-folders of level 2 and in all sub-folders.

For greater flexibility it is also possible to place a '.cpsskins_theme.py' script in the folder, which returns a tuple:

.cpsskins_theme.py:
return ('1-1:chalmers-2-blue', '2-0:chalmers-3-blue')

If such a script is present users will not be able to set local themes in the folder using the local themes management screen.

Performance

To increase overall performance all portlets are cached in RAM whenever possible and they are only rendered when needed. This makes it possible to display a page with tens of portlets in less than 0.1 or 0.2 seconds and thus increase CPU availability.

A cache management screen is available in the ZMI (Zope Management Interface) to monitor the amount of RAM used by portlets. The entire RAM cache can be purged manually.

Figure 12 - Statistics on RAM cache usage by portlets


Availability of CPSSkins and CPSPortlets

At the time of writing of this article CPSSkins and CPSPortlets are available as cvs snapshots. More work needs to be done before final releases of these products can be made available. For example:

  • writing an XML import/export plug-in for themes and portlets using CPSIO;
  • implementing portlet management screens (portlet visibility, portlet translation, portlet browser, etc.);
  • selecting document layouts on-the-fly using the "Document portlet"
Compatibility

CPSSkins and CPSPortlets are designed to be cross-platform but in order to use CPSPortlets under CMF/Plone, the CPS4CMF product is required.

References
Jean-Marc Orliaguet


shim
shim  ZopeMag is committed to bringing you the best in Zope Documentation. shim
shim


Home   Subscribe   FAQ   Contact   Write for us   Privacy Policy   Weekly News   PyZine   opensourcexperts.com  

Reproduction of material from any of ZopeMag's pages without prior written permission is strictly prohibited. Copyright 2003 - 2005 ZopeMag Zope/Plone hosting by Nidelven IT