Zope2 vs Zope3 FAQ

I see  many questions on the differences between Zope 2 and Zope 3 on mailing lists. Here is a short attempt to answer some of the most common ones.

Should I use Zope 2 or Zope 3?

Short answer:
If you need a product that runs on Zope 2, like for example CPS, Plone or Silva, you should use Zope 2. Otherwise you should use Zope3.

Long answer:
Zope2 and Zope 3 has slightly different target audiences. Zope 2 was ment as a webserver, where you could create dynamically generated websites and manage them through the web. However, Zope 2 was so powerful and the combination of true OO database and Python so developer friendly, that many people soon started to use it as a web application development platform, creating web applications that had nothing to do with the orginal concept of creating websites.

Zope 3 is directly and originally aimed at that type of application development. That means that is you are looking for a web development platform, you should use Zope 3. If your aim it to make a website, Zope 3 is currently lacking in that department. Mainly, a complete enterprise CMS is not yet available for Zope 3 (at least not as open source), so there is no substitute for CPS or Plone yet.

What about Five?

Five is a technology bridging the gap between Zope 2 and Zope 3. It is included in Zope 2.8, and it enables you to use many of the Zope 3 features in Zope 2. It is therefore mainly of use if you have to use Zope 2 for the above reasons, but you want to start using the nice Zope 3 programming patterns, such as views and adapters.

Currently, products written for Five will NOT run under Zope 3, and products written for Zope 3 will NOT run under Five. However, with every new release of Five and of Zope 2, it is intended to bring Five products and Zope 3 products closer and closer, thereby having a situation where only small modifications, or maybe even no modifications at all, are needed.

Hints for Zope 2 developers

As a Zope 2 developer, it's easy to get into the wrong programming patterns for Zope 3. Many of the techniques used in Zope 2 are not necessary for Zope 3.

Don't use stock objects!

A common pattern in Zope 2 is to monkey-patch the stock objects to provide more functionality. Typical examples of this is that you want to make all folders ordered, so you can change the sorting of the objects, or override all applications manage_afterAdd method to reindex them, and so on.

But Zope 3 is not a way to make websites. It's an application development platform. The application you create are not expected to use any "stock objects". There are not very many of them anyway. You are supposed to create your own objects and use them. This also means you don't have to monkey patch anything. In addition, events and adapters mean that have have better ways of changing and overriding functionality without any monkey patches.

Don't monkey patch!

See above: You shouldn't need to monkey patch in Zope 3. If you do, you are most likely doing something wrong. There is of course the possibility that you need to override something that should be overridable via some sort of configuration, but isn't, in which case this could be seen as a Zope 3 bug. Fixing Zope 3 bugs by monkey patching is OK, provided you also get the bug fix into the next release of Zope 3, of course.

Create your own ZCML statements!

ZCML is the Zope 3 way of configuring. It's only global configuration (configuration done on a site or folder basis needs to be done through the web at the moment) but all that global configuration should go into ZCML. It should absolutely not go into Python code. Why? Because ZCML is overridable. If you have in your product a default ZCML statement to configure your product, the people who use your products do not need to change your code to modify the begaviour of your product. Instead, all they need to do is create a new product with an overrides.zcml, and it will override your statements.

Making ZCML statement may be a bit confusing the first time, but once you got a hang of it, it's quite simple.