[<<] Industrie Toulouse

January 29, 2005

Zope 3 is a skinnable system. It comes with a new "Zope Management Interface", but a nice thing about Zope 3 is that you can write an application that uses Zope 3 that does not use nor care for the ZMI at all. Like in Plone and the CMF, Skins are set up in layers, with the ability to override where you might want.

The default skin for Zope X3 is a basic ZMI web interface. It's single screen now, not multi-paned like Zope 2's. But - it uses a javascript based tree for folder navigation. This tree works in Internet Explorer and Mozilla/Firefox, but not in the current release (1.2) of Apple's Safari browser (based oh KHTML). Zope provides an alternative skin, StaticTree for this situation. But I could not find StaticTree mentioned in the Zope 3 developers book. If I hadn't had to deal with this before, I would probably not have found it easily without searching through mailing list archives or the Zope 3 wiki. Fortunately, I did remember it. So I'm recording it here, as it was the first thing I had to do to really get Zope X3 usable "out of the box" for my preferred browser.

How to find out what skins are available: Zope 3 provides an excellent API documentation tool, readily available from the Help option in the new ZMI. From the API Documentation tool, I visited Presentations from the top navigation pane. In the bottom navigation pane was a link that said Show Skins and Layers. Clicking on that brought up a page showing all of the skins that are defined in the system, including which one is configured as the default, and the layers that makes up the skin. It also included references to where each skin and layer is defined - down to the file path and line number. On this page was listed StaticTree.

How to change the default skin: Most Zope setups these days run out of an instance home, basically a local set of files and scripts that runs the Zope app server and contains configuration for that particular running, while the bulk of the Zope system resides in a common location on the file system. Zope 3 uses this as well. In an instance home is the etc/ directory containing configuration files. One of these files that is important to customizing your Zope 3 instance is overrides.zcml. The default overrides.zcml is empty, except for a few comments, including a comment on how to set the default skin. Here's what the inner contents, sans comments, of my etc/overrides.zcml file looks like now:

	<browser:defaultSkin name="StaticTree" />

After restarting the Zope 3 web server, I can now see the navigation tree in Safari.

J. Shell, January 29, 2005 12:50 PM, in Zope

I saw a weblog entry from Titus Brown today talking about Python and Web Frameworks: It sounds like rewinding the clock by 5 or 10 years and building a leaner, meaner Zope with Python 2.2 would result in the similar advantages for Python: One True App Framework.

In theory, Zope 3 is just that. Without the clock going back five or ten years. Going back ten years, though, you do have just that in Bobo. The Python Object Publisher (ZPublisher in Zope 2, zope.publisher in Zope 3) is at its heart a very simple concept: publishing objects on a URL. I wrote my first Bobo application back in early 1997 and was amazed with how easy it was to take a healthy chunk of existing Python code and put it up on the web. It was much easier than Python CGI programming at the time. There was no grand framework to speak of - just a collection of tools one could mix and match as desired: Bobo for publishing, DTML (a smaller and simpler version of DTML than the one that exists now in Zope) for templating, and BoboPOS for object persistence. In a day, I converted an application that my company had been struggling with from a Java applet front end to a web front end. And half of that day was spent making pretty HTML.

Bobo did a lot of things right that were lacking in almost every other web system of the time, especially plain CGI programming. It's genius was that it was an ORB - an Object Request Broker - that translated HTTP requests and URLs into object calls and traversal. It even included some marshalling features to automatically have values come in as integers, floats, or other value types. My memories of Python CGI programming, which I last did about ten years ago, was that almost all of my time was spent getting data in from the CGI process into the right formats and into an object call, and then back out. I got to spend very little time with my application objects. Bobo turned that around completely. And now in Rails and other application systems like the impressive Seaside and its Ruby equivalient, Wee (which I think is a much more impressive system than Rails), you're seeing similar. But Bobo and BoboPOS did a lot of this stuff back in at least 1996, if not before. And it was on these basic tools that Principia, which became Zope, was built.

So if you rewind the clock ten years, there is a good, powerful, and simple toolkit to build a new system on. Yes - Zope 2 is a complex and strange beast. So what now? Zope 3. Zope 3 right now is actually called Zope X3. It has no backwards compatibility with Zope 2 and is still more of an experimental release. What it is is a complete rewrite of Zope that attempts to deliver the basic tenets of what Bobo offered while also providing a strong application framework that provides even more services. Chief among these services is a strong concept of object adaptation. And, as I wrote up (nearly 2 years ago), aggregation and adaptation is used more than inheritence. Objects aren't expected to know everything. Helper objects can be used or written as needed.

Now, I have not really used Zope 3 very much yet myself. Day to day business work keeps me in Zope 2 land as Zope X3 3.0.0 just barely landed. So after glancing over how to make a simple todo app in Rails, I've decided to try out Zope X3 to do something similar.

First step, installation. I'm running this on my desktop iMac G5, basic Mac OS X 10.3 setup - no MySQL installed or any crap like that. And the nice thing with Zope is that you don't need an RDBMS. Installation required getting an updated Python (the Python in Mac OS X is 2.3.0, and Zope requires 2.3.4), downloading the source release, and then the basic configure; make; make check; install routine. No further bindings needed. (Of course, Zope X3 can work with MySQL and other RDBMS's, but you don't need to). So installation went pretty smooth.

Also, for this, I'm going off of The Zope 3 Developer Book. Yes, virginia, there is documentation! So far, getting Zope 3 up and running has been pretty easy.

J. Shell, January 29, 2005 12:26 PM, in Zope