And you thought Zope 3 wasn't fun
=================================

If you think that Zope 3, or even Zope in general, isn't fun, agile,
developer-friendly, easily understandable or "Pythonic", enter Grok_.
Here's an excerpt from Grok's README file:

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

  Grok uses the Component Architecture and builds on Zope 3 concepts
  like content objects (models), views, and adapters.  Its simplicity
  lies in using **convention over configuration** and **sensible
  defaults** when wiring components together.  That means neither a
  configuration language like ZCML nor a lot of repitition are needed
  to create a web application with grok.

For the last couple of months, Grok has been developed by a handful of
Zope 3 core developers.  Like Five_ and lxml_, Grok was originally
thought up by Martijn Faassen at the EuroPython 2006 sprint.  After we
gave some input to Martijn's early design notes, five of us met for a
`first Grok sprint`_ in October.  This past weekend I had the pleasure
of hosting the `second Grok sprint`_.  A first release is only a few
weeks away, with a 1.0 scheduled some time in the second quarter this
year (after a third sprint).

.. _lxml: http://codespeak.net/lxml
.. _Five: http://codespeak.net/z3/five
.. _first Grok sprint: http://www.gocept.com/gocept-de/aktivitaeten/community/grok-sprint
.. _second Grok sprint: http://faassen.n--tree.net/blog/view/weblog/2007/01/09/0

Since there have been several blog articles mentioning Grok and its
philosophy already, I'd like to answer a FAQ that I get from
developers:

  So what does Grok code look like?

Imagine a simple web application for managing a herd of mammoths. For
the sake of simplicity, we only support adding a mammoth to the herd
and searching for it afterwards (more functionality like listing all
mammoths in the database or deleting mammoths can be added with few
lines of code).  Data persistence will be provided automatically and
transparently by the ZODB.  The searching will facilitate the Zope
Catalog utility.  All of this fits into one Python module:

.. include:: herd.py
   :literal:

The HTML of the default view for herds is rendered by the
``herdindex.pt`` template.  By putting it in the ``herd_templates``
directory, it will be picked up automatically and associated with the
view class in ``herd.py`` according to the name of the template file
and the name of the view class:

.. include:: herdindex.pt
   :literal:

That's it! That's the whole application! The only teeny bit of ZCML
that we need is for registering the application with Zope 3::

  <grok:grok package="herd" />

This will tell Grok to "grok" the components we defined and register
them accordingly.  No ZCML or any other configuration needed.  Just
take it out of the box and have fun.  (I should note though that
currently, this example will require some ZCML so that the initial
``Herd`` container can be created.  We hope to solve that problem by
the first release or the 1.0)

And you thought Zope 3 wasn't fun? We're just warming up!


**Update:** After receiving lots of feedback, particularly about the
``before()`` method on grok views, we decided to rename ``before()``
to ``update()`` in an attempt to make the name less confusing and more
similar to existing Zope 3 idioms.  ``update()`` can now also issue a
redirect which will cause the template not to be rendered
subsequently.  Thanks to `Martin Aspeli`_ for suggesting that.  The
code snippet above has been changed accordingly.

.. _Martin Aspeli: http://optilude.wordpress.com/

**Update 2:** Grok now has an ``Application`` base class for an
application's root object, so I updated the ``Herd`` class to use
that.

**Update 3:** Grok now has a web site at http://grok.zope.org!