Arc v' February 03, 2003

There are a growing number of alternative TAL (Template Attribute Language - the heart of Zope's Page Templates). One of these is OpenPT (previously known as AltPT). The curious thing is the feature bullet cited below:

OpenTAL can now read template configuration in the form <tal:config property="value" multiproperty="value1;value2" />. OpenPT uses this to possibly set properties (like encoding, handlers, preferred output encodings) via source; useful for webdav/ftp editing [Lalo Martins]

A good idea, but I'm not sure if it's the right implementation. It seems that since TAL does such a good job being a good XML/HTML player, something like this is best suited to processing instructions, something like <?tal config property="value" multiproperty="value1;value2" ?>. Of course, we'll have to remind the HELL out of people that <?tal is not PHP.

I wish I was here (almost). At the SolutionsLinux Expo, a Zope 3 UI sprint is happening, based on Jim Fulton's Through-The-Web development proposal. This is an area where Zope 2 gets tough when you:

1. Want to make persistent content objects in Python (aka "Products")
2. Don't want to use the CMF (it's too heavy for the project in question)
3. Don't want to use ZClasses (lack of familiarity)
4. Want to keep the application specific pieces (ie - "browser views", page templates and python scripts) defined in the ZODB, and not on the file system, for a richer UI. Yet the content objects need to get bound to views somehow, and those views have to exist somewhere logical so that they can be maintained easily using tools like Adobe GoLive.

This is not an unreasonable list. And usually ZClasses, using your Python products as the base class, do a reasonable job of holding view-level information, particularly if you refer to a common containing template (standard look and feel - typically "standard_template.pt" for page templates and the duo "standard_html_header/footer" for DTML). But for my application to work, this wasn't a valid solution (for reasons longer than I can go into at this time).

Much Zope development, particularly project's I've been involved in, have operated on one of two axioms:

1. First class views, second class data. This is where the data is coming from a non-ZODB source, such as a relational database, and the primary structure of the website is folders of templates/scripts/sql. This is similar to most web development.
2. First class data, second class views. This is where the primary structure of the site is made out of content objects, and the views are coming in from another source. This can be the filesystem and DTMLFile/PageTemplateFile objects, or the complex (and powerful) CMF "Skins" system, which is a folder containing a multitude of folders whose namespaces get compacted down to one where they can be accessed by the content objects in the ZODB. Usually there are some intervening tools to define which names to look for (ie - what's the edit form, what's the view template, etc).

What I'm needing - at the very least - is something like the second (first class data) without the weight of the CMF if I don't need it. I'm hoping that Zope 3 can deliver on this somehow. There's already a lot of really cool things you can do with views in Zope 3, at least at the file system level, that have been tricky to do up until now. Hopefully the Z3 UI sprint at SolutionsLinux can yield something decent here.

Lately, I've gotten to liking using fake namespaces when it comes to certain Zope things, particularly Permissions and Meta Types. I got the idea from Zope 3, whose core permissions include elements like "zope.Public", and am applying it to a current consulting project. All the permissions and meta types registered have a customer specific prefix (lower case). Two benefits of this -- (1) I ensure that at deployment time, there are no conflicting/confusing product names in the add list - if two customers have different Artifact objects, they're identified as such; (2) It groups application/customer specific objects and permissions together in the management screens. This is very nice, especially as security and permissions are often a key feature in getting contracts.

Another habit I've gotten into (and am expanding upon) is stronger use of constants, particularly for Permission names, but also for status values and other things of interest where I don't want to run into a typo. We started using permission constants in the CMF quite a while back now, and Zope itself picked up on this too. We now have the AccessControl.Permissions module, allowing a Product developer to use security.declareProtected(Permissions.view, 'example_method'). Not only does this look a bit better, but it helps protect against issues with typos in the permission name, allowing them to be caught at import time instead of weeks later (ie - catching the difference between "Access Content Information" and "Access Contents Information"). This is useful in one's own projects as well. I like to keep mine local to the module containing the content object I'm working on. Now that I'm trying this simple namespaces experiment, it makes it even better. And this leads to clearer product initialization code, like the following:

import customer
 
def initialize(context):
    context.registerClass(
        customer.Customer,
        permission=customer.AddCustomer,
        constructors=(customer.manage_addCustomerForm,
                      customer.manage_addCustomer,),
        )