I'm going to be introducing someone to Zope 3 starting tomorrow. The goal is to build a productive long-term contributor. I'll be investing a decent amount of time, and also be expecting a big investment of energy from the student.
To start off, I want to answer this question: what is Zope 3, and why do we use it?
Amazingly, one of the community's problems is that we don't agree on an answer. Steve Alexander gave a reasonable definition in a EuroPython 2004 talk, which Philipp von Weitershausen quotes in the first chapter of his book. Here's what Steve said:
Zope is
- a collection of free software
- jointly developed by Zope Corporation and a large community of software developers
- that you can use in whole or in part
- to manage complexity in gluing software components together,
- securely publish objects on the web and other systems,
- and make it easy to do Quality Assurance.
I'd agree with that, though I think the word "Python" belongs in there somewhere, and it's hardly an exciting marketing blurb for newcomers familiar with the buzz from other web frameworks. I guess I'll start with Steve's answer, but then I need to dig in.
- The "glue" Zope 3 offers is by working with contracts--interfaces--and providing a couple of lookup mechanisms based on the contracts--adapters and utilities. I'll delve into that a bit, and give some examples at the Python prompt.
- The "quality assurance" typically comes from doc tests of various types. I'll delve into that a bit, and then encourage writing some modules with it. Hopefully together we can come up with an interesting example package to work on, or else I'll have to come up with a random one.
Now we start veering away from Steve's definition--or perhaps veering into some of the details.
- Our persistence mechanism, at least at Zope Corporation, is almost always the ZODB. It is an essential part of becoming a productive long-term contributor at our company, so I'll delve into some details here, including talking about transactions and conflicts. We'll make the package from the previous step ZODB-aware.
- We can talk about events as a concrete example of our "adapter" lookup concept (as an aside, adapter may be a misnomer, and the evidence may be that it is not a helpful word to explain many of the uses to newcomers). We can probably make our package generate some reasonable events.
- Catalog integration is an obvious next step from a package perspective, and I regard the key reference and intid knowledge that would be part of the catalog discussion to be essential to expert use of the ZODB.
- Authentication and security touch on another of Steve's points and also are a concrete example of utilities. We'll want to delve into that.
- And finally, we have the web. The Zope object publisher, and specifically the Zope request is a core concept. Getting into views will highlight our flexibility but also our holes in comparison to other packages out there (as an aside, I wonder if we as a company or as a community can steal the widget work from some of the other frameworks, like the TurboGears ToscaWidgets?) We'll return to quality assurance with testbrowser doc tests to interact with the publisher and our views. And we'll want to dig into authentication and security again.
I like this, but I'm also leery of my predisposition to teach with too little initial hands-on excitement. I'll try to brainstorm some initial "wow" experience tonight and tomorrow morning. Maybe I'll split up my time between back-to-front teaching, as I describe here, and front-to-back teaching, as is popular with recent "write a blog in ten minutes" web frameworks. I do think Zope stands out from the crowd more when viewed back-to-front, at the moment.
