SkinsProposal

Skins tool proposal for the PTK

Problem

The PTK has long had a nagging problem: when you upgrade the PTK software, you lose all of your customizations. There was a nice "refresh skin" function that let you finish an upgrade easily, but it didn't get around the fundamental problem: users needed to be able to upgrade the PTK software without losing customizations.

Solution

Many different solutions were considered: CVS synchronization, LocalFS?, making the interface refresh function smarter, using transparent folders, creating a new type of ZODB, and so forth. But finally we decided on a new solution that has many merits: skins.

Skins are a lot like transparent folders in that a child folder is automatically searched for objects in addition to normal acquisition behavior. The difference is that skins can have multiple layers and it's possible for visitors to select the layers.

Some of the advantages of skins are:

They help separate data, code, and presentation. Data is stored in normal folders; code is implemented as a combination of classes, tools, and a special skin layer; and presentation is placed in different skin layers.
Users can create skins that layer over standard PTK skins. In custom layers the user only needs to add the objects that are customized. So when the PTK software is updated, the underlying layers are automatically updated.
Skins can be used as a simple versioning mechanism. When you want to change the portal interface without disrupting current users, just create a new skin and select it in your preferences. Note that this also allows users to preview future improvements and avoids issues that Zope's built-in versioning mechanism has with ZCatalog?.
Skins make a portal look cleaner in the Zope management interface. Instead of littering the portal folder with a bunch of DTML methods, all the presentation elements are neatly stored in skin layers.
Skins help a lot in the quest to make the PTK localizable.

How to use skins

The portal_skins tool, first made available in January 2001, is a folder that is capable of providing skins to the portal. When you create a new portal you'll find the skins tool already installed and populated with the standard PTK skin layers.

The "Properties" tab of the portal_skins tool is where you can create new skins. A skin is specified by a "skin path". A skin path is a list of layered folders, separated by slashes. The last item in the skin path is searched first.

The skin layers from the PTK software cannot be modified through the management interface. Instead, there is a "customize" button that lets you easily create a customizable copy of individual objects.

Risk Factors

Skins have a couple of potential disadvantages:

Retrieving an object from a skin takes a little longer than normal retrieval. But the difference is quite small and there are many ways to deal with this if necessary. The simplest option is to take all objects out of the skins and put them in the root of the portal.
This adds somewhat to the complexity of name lookups. Users may get confused. However, there have been no complaints of this complexity by the users of the TransparentFolders? product, which adds to the problem by not providing any way to select the ordering of transparent layers.
Currently, you should never put anything confidential or anything that has proxy roles in a portal_skins folder or subfolder. In order to provide flexible skinnability, we chose to make the assumption that anything found in a skin is not meant to be private. If this is an important issue for people, there are probably ways to solve it. However, using portal_skins does not compromise the security of objects not stored in a portal_skins folder.

Deliverables

Integration into the PTK. Done.
Documentation. More forthcoming.