E-Democracy Pages Wiki

Search Wiki




Page Components

From E-Democracy.org

Revision as of 08:26, 28 October 2013 by Wbushey (Talk | contribs)

Zope and GroupServer provide a sophisticated set of components and classes for building web pages. This set consists of widget like content providers and viewlet, to form building/handling classes, to general web page containers.

This set, in addition to Zope Templates, provides the tools a developer needs to display information and create user interfaces on E-Democracy.

Content Providers

While quite common in GroupServer, these are mostly being phased out in favor of the more flexible Viewlets and Viewlet Managers. However, understanding Content Providers will help new developers to understand Viewlets and Viewlet Managers, which are described below.

Content providers are indivisible content displays or UI components (aka widgets) - the providers of content and structure for complete components (e.g. a post) that can be included as part of an overall page (e.g. the topic display page).

Most Content Providers are declared in an egg's configure.zcml to have:

  • a name;
  • a class;
  • a template;
  • and maybe a factory or adapter

Content Providers are included on pages by using the tal:replace or tal:content tags and the structure

Site Content Provider


The base for content providers used on a site. It is simply an object with knowledge of the context, request, and view. It provides the following properties:

  • siteInfo - A groupserver.SiteInfo instance
  • loggedInUser - A groupserver.LoggedInUser instance

Group Content Provider


Base for content providers that are intended to be used in a group. This is a subclasses of SiteContentProvider, and provides the following properties that are relevant for groups:

  • groupInfo - A groupserver.GroupInfo instance.
  • viewTopics - Indicates if the user has permission to view topics in the group.
  • isAnnouncement - Indicates if the group is an announcement group.

Viewlets and Viewlet Managers

Viewlets are a more flexible means of constructing indivisible displays or UI components. Viewlet Managers are a container for Viewlets. Basically, a page or Viewlet, via its template, includes a Viewlet Manager. Viewlets attach themselves to Viewlet Managers, and any Viewlet attached to an included Viewlet Manager will become part of the final rendered page.

Viewlets and Viewlet are now the preferred way of constructing displays and UI in GroupServer, because they are more flexible (Viewlets can be added to Viewlet Managers by any egg's configuration) and are much easier to override (any egg can override a Viewlet or Viewlet Manager).

Understanding Viewlets by the Grok Project provides a good overview of the idea of Viewlets and Viewlet Managers, though specific implementation differs in Zope. The package documentation for zope.viewlet provides a lot of detail (too much frankly) on how Viewlets and Viewlet Managers are used.

Viewlet Managers

Viewlet Managers are usually a defined space that eggs can plug content into via Viewlets, so the interesting code is usually found in Viewlets.


In brief, a Viewlet Manager is often declared in an egg's configure.zcml. This declaration will usually include:

  • a marker interface (usually extends zope.viewlet.interfaces.IViewletManager)
  • a class (usually gs.viewlet.manager.WeightOrderedViewletManager or a subclass of it)
  • a template
  • a name
  • a layer if overriding a default Viewlet Manager

The template typically defines the layout of the ViewManager’s area and pulls in content from the Viewlets registered with the ViewletManager. Sometimes, this is nothing more than an iteration through the registered Viewlets.

While the interface and class can in theory define interesting properties or methods, these are usually quite bare.


Instances of a Viewlet Manager will have access to the current

  • context
  • request
  • view

In addition, viewlet managers provides a global options/viewlets variable (in templates) that is an iterable of all the available viewlets in the correct order.



Viewlets tend to be where the look of a display or UI component is defined, and where the fetching and processing of content occurs or is initiated.


Like Viewlet Managers, Viewlets are usually declared in an egg's configure.zcml. These declarations usually include

  • the interface of the Viewlet Manager being attached to
  • a class (usually gs.viewlet.viewlet.SiteViewlet, or gs.group.base.GroupViewlet, or a subclass of it)
  • a template
  • a weight (used for ordering in WeightOrderedViewletManager)
  • a title
  • a name
  • a layer if overriding a default viewlet

Note that it is entirely possible, and not uncommon, for an egg to declare a new Viewlet using interfaces, classes, and templates defined entirely in other eggs.


Viewlet classes tend to be more sophisticated than Viewlet Manager classes. Viewlet classes usually define properties that are used by the Viewlet's templates to display information. Viewlets classes often also include methods for processing information retrieved from data sources.

GroupServer provides a couple of Viewlet classes. When creating Viewlets for GroupServer/E-Democracy, the Viewlet class will almost always extend one of these classes.

GroupServer Site Viewlet


Very similar to the Site Content Provider above. This viewlet is used on site pages, and provides the following properties:

  • siteInfo - A groupserver.SiteInfo instance
  • loggedInUser - A groupserver.LoggedInUser instance

GroupServer Group Viewlet


Very similar to the Group Content Provider above (currently, this Viewlet is actually a simple wrapper of the Group Content Provider).

In addition to the properties provided by gs.viewlet.SiteViewlet, the following properties are provided:

  • groupInfo - A groupserver.GroupInfo instance.
  • viewTopics - Indicates if the user has permission to view topics in the group.
  • isAnnouncement - Indicates if the group is an announcement group.


GroupServer provides a number of Page objects, classes which can be extended to create a full webpage that is associated with some URL and context. They are based on Zope's Page objects, with a couple of additional convience attributes and methods (such as a SiteInfo attribute and the GSUserInfo instance of the current viewing user). Generally speaking, these Page objects are divided between Group page objects - objects meant for pages that are viewed within a group content (i.e. group home pages, topics, etc...) - and Site page objects - meant for pages viewed outside of a group context (i.e. site homepage, user profile page, etc...). These Page objects are also divided based on the primary purpose of the page, with Page objects available for pages that are meant to be viewed via a browser, pages that are meant to be email messages, and pages that are meant to take input from the user.

Browser Pages

Email Pages

Input Pages


Home - Mobile - Forums - Wiki - Blog - About - Help - Contact - People - Donate - Rules - Archives