What Zope Did Wrong, and How We Fixed It

Zope 2 was a great and revolutionary web application framework, but it also had it’s fair share of problems and design mistakes. Some of those problems came as a result out of the new revolutionary features. The through-the-web development turned out to be problematic to step away from if you wanted to move over to the more unrestricted disk based development, for example. Other problems just arose from increasing complexity over time, and Zopes monolithic design. Zope was also a trail blazer, and had to implement it’s own modules of many basic web framework parts, because they didn’t already exist elsewhere, which ended up isolating Zope from the rest of the Python community. Zope 2 is therefore full of dead ends.

Zope 3 aimed to fix these problems, but the way it was developed introduced it’s own problems, and when it was released it’s complexity has been a deterrent to get people to use it. There are no dead ends, and a nice architecture, but instead a huge learning curve.

This talk takes up the most glaring errors made by Zope 2 and Zope 3, presents an attitude to application frameworks that can avoid these problems, and discusses how the Zope and Plone community has been using these attitudes for the last couple of years to fix the problems of Zope, putting Zope back on the leading edge of web frameworks, where it belongs.

Outline including rough timing:

• What Zope 2 did wrong (13m) – The dead-ends – The learning curve – Unpythonic
• Zope 3: Knight in shining armour (7m) – Another learning curve – Death by abstraction – Zope 3 was bad for Zope 2
• How we can accomplish Power without Complexity (3m)
• How Zope 3 was transformed from another monolith (2m)
• Grok – A new way of developing with Zope. (5m)
• Rethinking the web stack: Repoze (5m)
• Zope 2 and Plone join in (5m)