The majority of content presentation systems currently used on the Web use HTML exclusively. Considering the growing number of browser applications and devices that support a variety of formats, including XHTML, SVG and WML, the use of HTML seems a needless restriction and a serious limitation for Web applications. This article demonstrates how the type of content emitted by the Zope application server can be changed between HTML and XUL.

The majority of content presentation systems currently used on the Web use HTML exclusively. Considering the growing number of browser applications and devices that support a variety of formats, including XHTML, SVG and WML, the use of HTML seems a needless restriction and a serious limitation for Web applications.

However, the solution need by no means lie in creating several different system versions for different device types, nor asking the user to select a format for presenting the requested data. This article demonstrates how the type of content emitted by the Zope application server can be changed between HTML and XUL.

XUL

The purpose of the XML User-Interface Language, or XUL for short, is to describe graphical user interfaces. It is used in all applications based on the Gecko engine, i.e. the whole Mozilla suite, Firefox, Thunderbird, Sunbird, Nvu and others.

Figure 1. Sample Zope screen seen in Mozilla Firefox

There are several ways of displaying XUL files in a Gecko-based browser. The first way is to open a local file by passing it as a command-line parameter or via File->Open. Another way is to have the server send a XUL file. For the Gecko engine to recognise the file as a XUL interface description, the Content-Type header should be set to application/vnd.mozilla.xul+xml. A third way is to install a browser extension (plug-in), allowing XUL files to be opened using URLs starting with chrome://. Finally, there is also a way of displaying XUL using just the Gecko engine itself, without a browser. The XUL Runner project allows XUL files to be displayed and XPCOM modules to be run without a browser, essentially providing a bare Gecko engine without a user application (Web browser, mail client etc.).

XUL elements reside in the namespace http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul. The root element for any XUL document is called window and describes the window that will hold other elements and be displayed by the browser. Each element (including all windows) can have an id attribute which should be unique within the file.

Presenting data using XUL

Data with an inherent internal structure is typically presented using tables, and the tree element is the most common way of rendering a table. A tree has two subelements: treecols describing table columns and treechildren containing actual table data. Each treecol element within treecols should have the id attribute, used to identify a column when displaying its data, and the label attribute defining the column header label. The treechildren element contains data represented by treeitem elements. Each treeitem should have a treerow child, which in turn should contain a number of treecell elements. Each treecell should have a label attribute to store the data for the column. If there are fewer treecell elements than table columns, the columns are filled with available values from left to right. A different data insertion order can be specified using the ref attribute to indicate the column (identified by its id) that the value should be written to.

If table height is not restricted by higher-level elements, it depends on the number of table rows. To specify a minimum tree height regardless of the amount of data, set the rows attribute to the number of rows to be displayed.

As the name suggests, the tree element can also be used to display tree-structured data, i.e. data that contains nested content. To make this possible, especially to allow child data display toggling, one of the columns has to have the primary attribute set to true. The column will then contain an icon for shrinking and expanding subtrees, and will always be visible.

Hierarchical (tree-structured) data is stored in the same way as table data. If a tree row contains child data, the treeitem element must have the container attribute set to true. After the treerow specifying data to be displayed in the top-level row comes the treechildren element, where the required subtree can be defined.

Joining XUL and HTML

HTML content can be embedded into a XUL file. To do this, the XUL file should include the HTML namespace http://www.w3.org/1999/xhtml, typically described using the html: prefix. If this is the case, all HTML element names should be preceded by this prefix. All HTML tags should be XML-compliant, with lower-case element names, all attribute values enclosed in quotes or double quotes and each tag explicitly closed - same as for XHTML, so Readers familiar with XHTML should feel at home.

Zope

Zope is an application server written in Python. The use of Python eliminates portability issues, both for Zope itself and any user-supplied code running within it.

The latest Zope version is 3.1.0. Note that releases from the 3.x branch are backwards incompatible with Zope 2.x, so Zope 3.x is currently marked as Zope X3, with the X signifying backwards incompatibility. However, Zope developers have announced that work on restoring backwards compatibility will start as soon as the current release has matured, allowing older Zope applications to be run with the new release.

Zope is a component-based system, allowing component and class code to be easily reused. The role of the programmer is to develop various specialised components and then tell the server how these components should be used and combined into an application. The creators of Zope suggest that components should be very simple, and component developers should not try to create multi-purpose modules. Although a great variety of components are available, for the purpose of this article we will be using just three types:

• content components - used for storing data; typically contain only fields, not methods,

• adapters - used to join different component types and adapt existing components to other uses,

• views - specialised adapters, used to change the default method of displaying content.

The component-based architecture allows Zope to support a variety of communication methods, and the base installation comes with several default methods. All object data is accessible through HTTP, FTP and XML-RPC, although access may occasionally require creating a suitable adapter. Due to the system's modular structure, no other efforts are required.

As with the majority of modern software, Zope uses interfaces to define service contracts for its components. Objects are accessed via interfaces exclusively, and the only places where you can encounter classes are configuration files that define classes as factories for objects with specified interfaces. Although the Python language itself provides no support for interfaces, they are provided by the Zope framework in the zope.interfaces.Interface class that each interface should extend. To indicate that a class implements an interface, we need to call the zope.interface.implements() method, which takes the names of the implemented interfaces as parameters. The call should come at the very beginning of the class, just after the class signature and doc. The Interface class also provides a few other methods, including providedBy() to check whether a class implements a specific interface and implementedBy() to fetch a list of all interfaces implemented by that class.

Although it may sound strange, the primary role of interfaces that describe content components is data storage, so (however bizarre it might seem compared to interfaces in other programming languages) it is quite common to have interfaces that only contain data fields and no methods. Each field is described by its name and type, with the type defining what data that can be stored in the component and how it should be displayed. Some of the most common types are:

• Text and TextLine - used to store text. Optional constructor parameters include min_length and max_length.

• Bool, Int, Float - equivalent to their Python counterparts. Constructors for the two numeric types can take optional min and max parameters.

• Tuple, List, Dict - equivalent to the corresponding Python collection types and used for displaying multiple objects. Constructor parameters include min_length, max_length and value_type (for specifying the value data type). The dictionary type constructor also has a key_type parameter for specifying the key data type.

All field type constructors can also take the following parameters:

• title - field name to be displayed,

• description - field description to be displayed,

• required - boolean value to indicate whether a field is required when creating the object,

• readonly - boolean value to indicate whether the field contents are editable,

• default - default field value,

• order - specifies a field display order different to the field declaration order.

Zope uses field type definitions to generate suitable HTML code, so no manual HTML coding is required. Each class defines two display objects: one to display data and one to fetch data of a given type.

Figure 1 presents a typical Zope screen. In the top left corner, you can see a tree structure corresponding to the objects within the current server instance. The particular branches can rolled up or expanded. Below that is a list of objects that can be placed at various locations throughout the object tree. Click an object name to be taken to a page for providing the required information for creating an object instance. At the top of the main panel, you will see lists for selecting the display method and content for the current object. The Introspector tab contains all object implementation code, including classes, superclasses and interfaces, which is very useful both for learning and debugging purposes, as it shows the way Zope sees objects. Below that is a list of commands available for the object, followed by a view of the object itself.

A d v e r t i s e m e n t

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence