Personal tools
You are here: Home About Grok: the Zope Toolkit for cavemen

Grok: the Zope Toolkit for cavemen

Grok is built on the ZTK.

Grok stands on a giant's shoulder.

Grok stands on a giant's shoulder. That giant is the Zope Toolkit (ZTK).

The ZTK is a collection of libraries and mini-frameworks. Together they offer an advanced object oriented approach towards web development. The ZTK features a large amount of API documentation and aims for reliability. It has a very large automatic test coverage (many thousands of tests). It has a large set of core features, and sports an enormous range of plug-in components.

The Grok developers use the ZTK as the foundation of Grok. Grok turns it into a complete web framework, and also puts a twist on some of the approaches in the ZTK to make them easier to use. This is because the power offered by the ZTK can raise the entry barrier for developers. In addition, the ZTK's emphasis on explicit configuration and specification of interfaces can slow down development.

Grok aims to tackle these problems. Grok builds on the ZTK to create a web framework that's easy to learn, and agile to work with, while retaining the underlying power and compatibility with other systems that also use the ZTK.

Grok appeals to the caveman or woman in all of us. Cavemen, like us programmers, want powerful and flexible tools. Cavemen are great at tools after all; they invented the whole concept of them. But cavemen, and we, also want our tools to be simple and effective.

Cavemen want tools like clubs: a club is powerful, flexible (you can bash in anything, mash potatoes too) and also simple and effective. The ZTK is already powerful and flexible. Grok aims to make it simpler and more effective, for beginners and experienced developers alike. Grok: now even cavemen can use the ZTK.

A little bit of history

The history of the ZTK is somewhat complicated. Since you will run into some of the older terminology involved when you read documentation, we will give a quick run-down here.

In the beginning (the late 1990s) there was just Zope. A version two of Zope was released quickly, but the fundamental nature of Zope 2 did not change. This version of Zope still is the basis of many projects, including the popular CMS Plone.

Then in the early 2000s the Zope community started a new project named "Zope 3". The original intent was for this project to eventually replace Zope 2, taking many lessons learned from Zope 2 into account.

Over time it became clear that Zope 2 was not so easily replaced. Instead, many Zope 3 libraries were adopted by Zope 2 developers and made an integral part of Zope 2 as well. Zope 2 and Zope 3 existed in parallel, sharing a common base. Then in 2006, Grok was built on top of Zope 3.

It became clear that Zope 3 was fulfilling two roles: as a foundational set of libraries for web frameworks, and as a web framework of its own. The naming of Zope 3 was confusing, as it suggested it being a successor to Zope 2 while it is not.

In 2009, we therefore reorganized the foundational set of libraries in Zope 3 as the Zope Toolkit. This is a base shared, at least in part, by Zope 2 and Grok. Finally in early 2010 the old Zope 3 was renamed BlueBream, which is also built on top of the ZTK base, just like Grok. Since BlueBream, Grok and Zope 2 all share a ZTK base, much code written for one project can, with some care, also be used in the other project.

To summarize the current state of affairs, there is a collection of libraries managed as the ZTK that forms the basis for Zope 2, BlueBream and Grok.

Grok from the ZTK perspective

The ZTK allows you to combine different components in an explicit, flexible way. You can hook up a view to a model, an event handler to an event, and a new API to an existing object. The process of doing this is called configuration. In a technical sense, an important part of Grok can be understood as being an alternate configuration mechanism for the ZTK.

The standard ZTK approach is to use ZCML for hooking up objects together. ZCML is an XML-based configuration language. ZCML statements are stored in their own file, next to the code. While using ZCML has the benefit of being explicit and flexible, it can also make code harder to read as there are more files to consult in order to understand what is going on.

Grok does away with most ZCML. Instead it analyzes your Python code for the use of certain special base classes and directives, and then "groks" it. This grokking process results in the same configuration as it would have if you used the equivalent ZCML. We believe that having all configuration along with your Python code makes the code easier to follow and more fun to develop.

Grok has been designed so that if you organize your code in a certain way, you can even leave out most of the explicit directives in your Python code. This makes code written for Grok look clean and uniform. You still have all the power of explicit configuration available should you need it, however.

During the development of Grok we have taken a careful look at common patterns in ZTK-based code and configuration. Grok aims to make these patterns more easy to use and succinct.