Why ZClasses are dead and why Grok lives
========================================

Recently there has been a bit of `discussion on the zope-dev
mailinglist`_ about ZClasses.  To those unfamiliar with this
particular Zope 2 institution, ZClasses are a way to compose content
types ("classes") using through-the-web (TTW) development techniques.
You would define one or more base classes, give it a name and then add
methods (= views implemented as DTML, ZPT or PythonScripts).

Among Zope developers, ZClasses have been discouraged for a while.  As
of Zope 2.9, ZClasses don't work anymore. Something broke their
fragile code.  They're officially dead.  How has it come to that?

.. _discussion on the zope-dev mailinglist: http://mail.zope.org/pipermail/zope-dev/2007-April/029278.html

ZClasses: 1000 years of cruft
-----------------------------

Why has nobody cared to fix ZClasses if they're so great?  Well,
because most developers first of all don't care about ZClasses (more
below), and second of all they don't understand their magical code.
In fact, one of my favourite quotes from Zope source code ever is from
ZClasses::

    def _setBasesHoldOnToYourButts(self, bases):
        # Eeeek
        copy=self.__class__(self.id, self.title, bases,
                            hasattr(self._zclass_, '_p_deactivate')
                            )

I'll let this code speak for itself.

Sure, they're agile, but...
---------------------------

Back in 2000, ZClasses were cool because they allowed for rapid
prototyping and agile development like no other tool.  It's 7 years
later and the world has changed.  Ruby on Rails, for example, has
taught us that actual code, written in a dynamic language can also be
agile, if you enforce or at least encourage certain defaults.  Django
and TurboGears have done the same in the Python world.

File system code has lots of advantages over TTW code, as I've pointed
out in an `earlier post`_.  It is because of reasons presented in that
article that people just don't care about ZClasses anymore.  It is
also why many people in the Plone community, for instance, care less
and less about the TTW development model.  I can understand them.
Standard file-system based Python development, especially with Zope 3
components, is much more appealing to experienced developers, who
after all make up the Plone and Zope core developer teams.

.. _earlier post: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_03_27_meet-grok-successor

Zope 3 - the answer to life, the universe and everything?
---------------------------------------------------------

Now Zope 3 is an incredibly powerful framework.  Jeff Shell, who
didn't always have nice things to say about it (apparently it drove
him back to smoking), `just now wrote`_:

  We've been using Zope 3 in earnest for just over a year and a half
  now. I would like to report that in that year and a half **our
  little company has achieved more re-use than at any time in our
  history.**

.. _just now wrote: http://griddlenoise.blogspot.com/2007/04/reuse-and-non-use.html

But Zope 3 isn't exactly known for its agility.  Those who've been
defending the TTW use case, be it some of the Plone folks or
Christopher Lozinski make a good point: how on earth is somebody going
to learn interfaces, ZCML, security declarations, etc. just to
customize a teeny bit in Plone?  Or just to write a simple application
for his boss?

"They don't have to" is Grok_'s answer, and the friendly caveman goes
on to say: "But they also don't have to give up that flexiblity given
to us by Zope 3."

.. _Grok: http://grok.zope.org


Low bar for contributions
-------------------------

This ZClasses discussion has also made me aware of another good point.
Christopher Lozinski, who's repeatedly come to the zope-dev
mailinglist, willing to contribute to ZClasses to keep them alive,
hasn't been able to write a single of code yet to so.  Why? As a
*user* of ZClasses, it's almost impossible for him to tackle the magic
that lies in the code of ZClasses. Heck, if some core contributors
can't do it without a considerable amount of time (hence money), how
should he?

With Grok, on the other hands, we now have newbies contributing to the
Grok source code itself only after a few months.  Tim Terlegard, whom
I trained in Zope 3 only a few months back at the `Lovely Training in
Copenhagen`_, has implemented JSON functionality for Grok.  Darryl
Cousins has been enhancing Grok's admin UI as well as fixing bugs and
writing tests. Kevin Smith has been looking into implementing layers
and skins. They've all been with Grok for only a few weeks or months.

This is what makes me confident enough to think that we're on the
right track with Grok.

.. _Lovely Training in Copenhagen: http://worldcookery.com/Training