Introduction

Web sites today are about much more than document delivery. They are focused on doing business online. One particular class of web sites is the portal.

Though portals are particularly poorly defined, two definitions are useful. First, Jakob Nielsen defined a portal as "the big three": news, search, and directory. Builder.com classified different types of portals, ultimately claiming that "the most popular features of a portal are Web searching, news, reference tools, calendaring, and communication capability."

The Zope Portal Toolkit (PTK) project uses a definition that leverages what's good about Zope and the patterns Digital Creations sees in its consulting practices. Thus the PTK has a portal vision.

A portal is a window into an organization's practices and processes. The purpose of the portal is building relationships and establishing gravity for an organization to attract readers and contributors, and to organize and manage diverse content. A key feature of a portal is that it is centered on the user (aka member). Its goal is to provide a highly user-centric user-dependent view of the organization's brand and resources.

The PTK provides two very important pieces: a framework for constructing custom portals, and an out-of-the-box, useful sample portal. These two pieces are critical to remember, as the PTK aims to be both a framework and a product.

The key services provided by the PTK are as follows:

• Search. The PTK leverages the ZCatalog to provide high-speed fielded and full-text searches of portal content. Since PTK-aware content notifies the ZCatalog when it is modified, the index is rarely out of date.

• Directory. PTK content can be organized into a hierarchical topic/subtopic system like big portal sites. Each topic acts as a virtual Zope folder, where the contents are specified by a ZCatalog query. Each topic, though, can contain regulary Zope objects such as graphics, templates that customize the presentation, and even discussions. Topics can also provide an RSS feed to syndicate content into channels.

  Under this system, content can appear in multiple places on the site on the basis of the content of the content, meaning the body text or properties.

• Membership. The most visible part of the PTK is the membership system. As discussed below, PTK membership extends the Zope user model to include cookies, external data, an arbitrary properties. Members can join automatically, the entire process can be customized, and members get their own area to work in.

  The last part is the biggest difference with a PTK portal versus other portals. With the PTK, content is generally authored in a member's area, then placed into the "public site" by means of the catalog. The goal is to let members think very clearly about "their stuff". When they want to add a news item, rather than transporting them to the news item area, just let them create a new item in their area. Thus, the PTK is focused very much on a me-centric model of content.

• Reviewing. By default, when a member authors a piece of content, the content isn't part of the "public site". When a member requests that a piece of content get reviewed and the content is approved, it becomes part of the "public site".

  The PTK includes extra roles to help this model. First, Managers can turn Members into Contributors, meaning their content doesn't require review. Next, Reviewers receive email notifications and can approve content that needs reviewing.

  The goals of reviewing are straightforward. First, Members with insufficient privileges should have their new content reviewed before it is visible. In this case, visible means the URL to the content should not reveal the content, the content should not show up in searches or topics, and the content should not be syndicated.

  However, there is more to the policy than this. First, different Members might have different authority. For instance, by default the content managed by Contributors needs no review. Next, the decision about whether an object is visible is different for each role. That is, a Manager should be able to view or search for anything. Most sites will also want to make reviewing extend to edits and even deletes as well as additions of content.

  Additionally, content can move between a reviewed state and an unreviewed state. In many cases one Reviewer might decide to override another's decision. When many Reviewers are involved, they need to efficiently get a list of the things in the queue. As Reviewers perform actions on content, these reviewing actions need to be recorded, perhaps including comments about the action.

  The PTK architecture accomplishes this set of goals with a combination of reviewing metadata, connections to the standard Zope permissions machinery, and metadata in the SiteIndex, which is the default ZCatalog for the portal.

• Syndication. PTK provides facilities that assist in creating RSS-based channels for content syndication. The PTK does not currently provide a facility to syndicate remote content.

• Integration. The goal of providing a single view of diverse organizational content means that the PTK needs to integrate external data into the content management system. The first steps have been taken by allowing membership data to come from external sources.

• Document. This is where most of the content and pages on the site will be created.

• News Item.

• Link.

• Discussion.

The key benefits for a Zope PTK portal are as follows:

• Me-centric content. As discussed above, members author content in their areas, then let the catalog place the content into the appropriate place. Members get a clear view of "their stuff".

• Turning over control. Members can create specialized forms of content in their own member area which can be woven into the portal site.

• Reinforces benefits of Zope. With portal content represented as Zope content, many of the Zope benefits apply, such as versions and undo.

• Extensible. The PTK framework was designed from the beginning to be easily altered and extended.

• Dynamic. All pages, including searches, are up-to-date. All aspects of the system can be tailored to individual users.

• High performance. PTK-based sites should start at a million hits a day on a cheap machine and go up from there.

Quick Start

While the original goal of the PTK was to provide a foundation for creating portal software, the PTK also provides an out-of-the box ability to create arbitrary portals. This chapter discusses how to create and use a portal from the various audience perspectives.

PTK Architecture

As mentioned above, the PTK architecture is designed to leverage Zope and to be extended as a toolkit.

The PTK exists as a Zope Product, which is a set of code and data that is installed into a Zope distribution to create new kinds of things that can be created. Installation of the PTK Zope Product does two main things: install the framework into the Control Panel of Zope, and make Portal a new kind of thing that can be added to a Zope Folder.

The Membership component of the PTK adds a number of major pieces over the standard Zope acl_users functionality. First, membership data can be extended to collect arbitrary properties about users. Next, the membership data can come from a relational database as well as the Zope object database (ZODB). Users can be authenticated by cookies as well as HTTP authentication. Additionally, the entire process of handling users is exposed to customization through the Control Panel. Finally, users are associated with a default Home Folder, similar to home directories in various operating systems.

Allowing the membership data to be stored in a relational database provides a number of benefits. First, some people just feel better with that data being external to Zope. Second, Digital Creations has been consulting with customers that wish to have millions of members, and these customers feel that a commercial database server will scale better. Third, some membership data might already be collected in a database. Finally, storing the data externally allows other applications to access membership information.

These are all major architectural changes over the default Zope facility for User Folders.

In the PTK, the content is stored in the ZODB. This delivers many of the crucial facilities. The catalog, which provides much of the strength in the PTK, is a ZODB facility.

The new products packaged in the PTK software are a combination of ZClasses, Python Products, and Python Methods.

Note that the PTK membership architecture does not provide one facility long hinted at: per-application preferences. That is, application developers are not given a facility to store per-member configuration information with the member.

The PTK adheres to the Dublin Core metadata initiative for the attributes used in content. The relevant data elements are identifier, title, creator, subject, description, type, and date.

Roles in PTK

The portal toolkit turns over control in a system of gradually increasing roles. Each of the following correspond to a kind of actor in a portal.

• Guest. This is the role for unauthenticated non-members, namely the general public.

• Member.

• Owner.

• Contributor.

• Reviewer.

• Manager.

• Administrator.

Portal Interface

The PTK provides much new machinery for Zope, but also aims for another goal. Zope itself was designed as a platform, not an application. Thus, the classic Zope management environment was by need quite verbose and not immediately discoverable. The PTK, though, works very hard to be a new breed of Zope application.

Particularly, the PTK interface was designed to be simple. Fewer knobs are provided, multi-step wizards provide verbose descriptions of steps, and users are visually reminded of things like Undo. A link to the classic Zope management environment is provided as a fallback into a "power user" mode. Additionally, the work on a next-generation "Zope Studio" might yield a "fall forward" into a more powerful interface for portal management.

In short, the classic Zope management interface focuses on both content managers and developers. The PTK-specific interface examines what can be done when only content managers are the focus.

Here are the differences of the PTK interface from the classic Zope interface:

1. Focused on content managers. This is the overarching design goal.

2. Stripped down. Content managers seldom use all the knobs in Zope. If they need them, Advanced is just a click away.

3. Continuous browsing and managing. Zope currently gives quite a "thunk" when changing from viewing to managing. The PTK interface combines the two modes. First, the look and feel of the site is shared in the management mode. Second, managing is usually just browsing with a few extra control areas inserted.

4. No frames. Using a frame-oriented management screen often leaves new Zope users in a weird state when switching between browsing and managing.

5. Cleaner desktop. The desktop area has no tabs and the add list is replaced by a button that leads to a more descriptive, helpful content creation facility.

6. More natural manipulation. Clicking on items in the desktop leads to viewing the items. To manage the item, users then click on the control to shift into management mode. More importantly, to manage an item while viewing it is just one click to switch modes.

7. More verbose. The PTK design exchanges a terse, productive interface for a verbose, helpful interface. Content creation is broken into multiple steps (i.e. wizards).

8. Structured Text. The content creation facility in the PTK is more oriented towards structured text. Zope.org was a first step in this direction. This means, obviously, the structured text will be better documented and will be "pre-compiled" rather than re-parsed on each request.

9. Only PTK-aware content. The only things that can be added are the PTK-aware things. This means that all the kinds of things seen by PTK authors have the new, easy interface and wizard-driven creation.

10. Contents in batches. The items shown in the desktop are shown in batches, with controls to browse between batches.

11. More prominent safety net. In the box on the page that has management controls, Undo is displayed prominently. Thus, wherever you are, recovery from a problem is just a click away.

The interface is designed to become part of the browsing interface, rather than a separate interface. Thus, the pages do not change very much when moving between a browsing operation and a management operation.

There are two major regions of the page for the interface. The first is the Member Box, as mentioned previously. The second is the Desktop. This region displays the page contents when viewing a resource, and displays the management view of a resource or a folder when managing.

The PTK interface has a number of style provisions. Optional fields on forms are in italics. Links that lead to another step have ellipses after them, such as New....