Charlie Clark was talking about his Zope3 experiences and why it is a great framework to work with and here is my try on a summary:
He started with a brief history of Zope2, how it started, how the CMF came up, introducing new concepts, like Filesystem development, Skinning support and a standard set of tools.
Zope3 was then meant to overcome problems in Zope2 and the CMF. Development started in 2001 and aimed to be a „Zope for developers“. It was a complete rewrite and complete redesign. In the meantime Plone and other projects such as Ruby on Railes and others raised in popularity.
The business view
If you are a company it is important to get paid for your programming work. You will always have a technology lag though because you usually cannot be always on the cutting edge with all people. You try to differentiate yourself from the market by IP, packaging up your software etc.
But don’t bet your business on it!
(didn’t get the rest though unfortunately)
Is Zope right for you?
What is available? Plone is out there but migrating Plone versions is a pain but might get better.
You can also use CMF and Zope2 to have more flexibility but in fact you maybe directly should look at Zope3 but maybe not the whole thing directly.
Reasion: The Joy of using Python.
Don’t Panic!
Zope3 is big but not complex. It just is different and it takes a while to get used to it.
Some figures: Plone objects have about 750 attributes when you instanciate them, CMF objects about 350, Zope3 objects about 50, mostly less. The less attributes you need to understand, the better.
What’s good about Zope3
First: No acquisition. Back then it was quite a great invention in a CGI environment but unfortunately acquisition can have unpredicted sideeffects (esp. regarding security). In Zope3 it has been removed and you might need to get used to it.
The basic principle: Explicit is better than implicit.
Zope3 also has the Component Architecture which is great in itself but sounds rather complicated. The amount of configuration probably is what keeps people away from Zope3 right now. But configuration also has it’s benefits because programmers and computers know exactly about what’s going on here.
One question: Do I need components in a one-off site? This is a loaded question which can create a lot of discussions. But when you use it you can later get a lot of flexibility. Also remember that maybe in your next project you might want to reuse part of what you did for the one website. Using components then makes it easier.
Everything is an interface
One of the key concepts is an Interface, which is not just a specification but also a membership card. It’s a way to get to stuff.
Documentation considered harmful?
Documentation for Zope3 is right now in READMEs mainly. It is unfortunately not as well documented as other projects which is a barrier of entry for many people. The code is readable but some of the concepts are somewhat abstract esp. for people who never used adapters etc.
But there is a great book: Web Component Development with Zope 3 by Philipp von Weitershausen. For Plone there is of course Martin’s book which also explains parts of Zope3 like adapters etc.
Zope 3 in 5 minutes
- Write your interface
- Write your content type
- Configure your content type
- Views
- Configure your view
Our experience
- PHP programmers can migrate to Python
- HTML developers are very happy with ZPT
- Allow two months to transition
He then demoed a simple reimplementation of a Plone document type with Zope3 mechanics. He defined an interface, create a content type which derived from PortalContent of the CMF and configured it. He then showed the browser part of it where the views get defined.
(this transcript comes without any guarantee for correctness)