Personal tools
You are here: Home Members cawb Zope Component Architecture
Document Actions

Zope Component Architecture

OK. I've bitten the bull by the horns and charged the world of Zope 3.

Zope Component Architecture

Zope is written in Python

Zope 3 scares me. I first investigated it when Zope 2.5 was released and it was like a barren world, devoid of features and documentation dry.

It's much better now, I hear, so I'm reading this very elegant tutorial on the future way to develop for Plone. Oh it's a headache.

The notion of documenting your interfaces before you write any code is deeply appealing: "I've had an idea and it works something like this", but it really is a whole new can of worms.

I like the idea that the interface is a contract between components, which allows the developer to pick-and-mix his library and know whether one component is a sufficient replacement for another. Engineers like to read the specification and decide if it will do the job: that's what an Interface offers.

The heavy expectation of unit testing and the ease with which these can be attached to doc strings even makes the whole process seem reliable and managable.

Nevertheless, we're back into the Black Magic world, where you're setting things up and believing they work, hoping against everything that the documentation is right and that these features really do what they say.

I don't have time to read the Zope source. I barely have time to read the new Plone products list. Here's hoping that these components make us genuinely more productive. Otherwise it will be another headlong charge into the cul-de-sac of the unknown.


Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: