Document Actions
1.5.
The role of Zope 3
Up one level
Zope 3 is the new, cooler, faster, sexier version of Zope. Unfortunately, there is no direct migration path from Zope 2 to Zope 3. However, we are beginning to use Zope 3 technologies in Plone, alongside the Zope 2 core.
Zope 3 is a fairly different way of programming. It is based on the principle of components, that expose their functionality through well-defined interfaces. Whereas in Zope 2, you would need to mix classes into the inheritance hierarchy to gain certain functionality, for example by mixing in CopySupport to get cut/copy/paste support, Zope 3 uses the principle of adapters.
An adapter is simply a piece of glue code that can adapt an object to a given interface, so that the original object itself doesn't need to know anything about that interface or what it does. This makes it easier to re-use other Python objects that are not Zope aware, and makes components smaller, more precisely defined and thus easier to re-use.
Other types of Zope 3 components include utilities - stateless, global objects that can be looked up through a generic registry, and views, a special type of adapter that is typically used to contain the logic of page templates in a way that is more performant and easier to test.
Porting Plone wholesale to Zope 3 would essentially involve a re-write, and would break every installation, third party product and customisation out there. It is simply not an option. However, because Zope 3 is built out of small, re-usable components, we can use certain Zope 3 technologies today. Starting with Zope 2.8, the whole of Zope 3 ships as an add-on library and is available to use for Zope 2 applications like Plone. Over time, more and more parts of Zope 2 will get re-written to use Zope 3 technologies. This is accomplished via a product called Five (what's Zope 2 + 3?) that performs some magic to make the fundamental Zope 3 building blocks usable in Zope 2.
Zope 3 integration begun with the Plone 2.5 release cycle, and will continue gradually over time. That means that developers will have to start learning Zope 3 concepts. At the moment, there is still some overlap between what can be done with "old" techniques and what can be done in Zope 3. There are also dependencies on what happens in CMF and Zope 2 in general before certain things become available.
However, the basic mantra starting with Plone 2.5 is:
- New components should use Zope 3 technologies whenever possible and appropriate
- Any re-factoring of existing code should use Zope 3 technologies where possible and appropriate
This means that page templates with complex logic should use views. Any new component should make proper use of interfaces and adapters, and existing components should get interfaces and use adapters if at all possible.
It is important to realise that this is a gradual process, and there are many pragmatic decisions to be made. In general, you should always consult the developer list, the release manager or other members of the development team on non-trivial design decisions.
You can learn more about Zope 3 from one of the published books, from Philipp von Weitershausen's WorldCookery web site, from this tutorial or from the rest of documentation area.
