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
Should I use Zope 2 or Zope 3?
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.
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
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
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
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
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.
(Post originally written by Lennart Regebro on the old Nuxeo blogs.)