[Grok-dev] Re: Teach me Grok

[Martijn Faassen]

Hey Johathan,

Welcome!

Jonathan Ellis wrote:
> Okay, that's a big subject. :)  Let me narrow it down to something 
> hopefully more manageable:
> 
> * Grok offers a lot of building blocks for your web application. *
> Grok is informed by a lot of hard-earned wisdom.
> 
> What are some specifics?  What does Grok give me that, say, django 
> does not?

Big question still! Grok is an integrated megaframework. That is, it
features replaceable best-of-breed components (megaframework) while
still aims to give you an integrated feel (the parts tend to follow
style guidelines and make use of the component architecture).

On to your question on what Grok gives you that Django doesn't. I'm not
sure whether Django can add a view to a content object defined in an
altogether different package. Grok is built around patterns that let you
do this - the component architecture. Extensibility and evolvability
through views and adapters and event handlers. In longer-term or larger
applications such a general way to extend and evolve and application
becomes quite important.

Concerning components, I believe we have a lot to pick from. We can
still do a lot better in presenting the components that are available in
the Zope 3 world, and I don't promise that all these components are
equally mature, equally integrated in Grok (there's no need for this
except to make life easier, though), or that they are easy to adopt, but
I'll give you a grab bag list of some of the things here:

* manage part-of-page views, per context object, per view, per area on
page, per skin (viewlets)

* manage vocabularies (for drop-down lists, say)

* display HTML tables

* auto-generate forms from schemas, with a wide selection of widgets

* integrate with ORMs (Storm, SQLAlchemy)

* authentication (basic auth, session auth, pluggable infrastructure on
where to get users, etc)

* authorization: users, groups, per-user/group per-object permissions
and roles

* REST, JSON, XMLRPC, WebDAV

* i18n, localization of things like date/time, country names, etc

* locking and freezing objects

* sending, queuing mail

* workflow

* XML-export and import of schema-driven content

* making objects appear in multiple places at once in the traversal
hierarchy, including generating correct urls for them and the urls of
sub-objects (zc.shortcut)

* versioning objects in a version control system (zc.vault)

* object indexing and search (grok.Indexes makes this easier)

* lucene, xapian indexing integration

* relation indexing (zc.relation)

* caching, support for protocols like ICP (zc.icp)

* unit testing, doc testing, fake browser doc testing, driving selenium
from browser doc testing, driving a real browser from browser doc testing

These components are are typically packaged as eggs, are doctested
(frequently extensively so), and define explicit APIs (using
interfaces). They use the component architecture for extensibility
points. They share a uniform extensibility mechanism.

What we're trying to do with Grok is to mine this pool of components to
try to make their initial use easier. That doesn't mean that you can't
use them out of the box anyway without efforts on our part - Zope 3 and 
Grok are compatible. But with Grok, we consider the existence of a 
component the half-way-point; now that it's there, we should make it *easy*.

> My impression is that in the past couple years the rest of the world
> has rapidly caught up to zope3; is that incorrect?

I think it's a mix. On the one hand, the rest of the world has been
doing all sorts of things (like MVC and automatic form generation) that
Zope 3 has been doing for a while, and also of course things that Zope 3
didn't do yet (ORM is an example, though we had early pioneering in that
area with things like ZPatterns, back in '00 or so).

On the other hand, the rest of the world doesn't use object databases 
(which some people still see as "future magic", though it obviously also 
has drawbacks), or advanced permission-based security, and is behind on 
the curve in catching up on extensible, buildout systems. I also have a 
suspicion (that I cannot prove) that the use of an object database makes 
the combination of content-components and configuration-components into 
new higher-level frameworks and applications more easy than is perhaps 
the case with relational database backed system.

I think Zope's strongest area is the component architecture, which
provides a uniform system for extensibility. We've seen a vast explosion
of components over the last few years - evidence that the
component-driven approach is working. You can look at the index page of
svn.zope.org to get an impression (and there are also quite a few
components maintained elsewhere, such as in the Plone collective).

Again though, this is a sucky presentation of what's there, and of
course some of these components will be better maintained and more
useful than others.

> Question 2, to people who came to zope via grok instead of the other 
> way around: how quickly did you find you had to learn about zope3
> gory details?  I.e., how leaky of an abstraction layer is Grok?

Grok isn't an abstraction layer over Zope 3. It's therefore very leaky.
:) Technically, it's an alternative configuration layer, replacing ZCML.
It replaces ZCML pretty effectively, and I'd say there's not much that
leaks there - we only use ZCML to trigger the whole grokking process,
typically.

Philosophically, Grok is an approach towards Zope 3 that makes it more
agile in use and more easy to learn. We try to reuse existing 
components, putting them together for 90% of the use cases, where
straight Zope 3 just offers a giant roll-your-own toolbox. We add 
convenience features. We try to create simple documentation. When I read 
about the TurboGears 2 effort, I figured it was trying to do with Pylons 
what Grok is trying to do with Zope 3. This is a big continuing effort.

If you are going to do hard stuff, you are going to have to try to
understand the various Zope 3 components you want to do hard stuff with. 
Gory details galore there. I believe that this is inescapable. What we 
*do* try is push the boundaries of what is actually hard. Zope 3 
components do this by offering new features and building abstraction 
layers. With Grok we add easier assembly, and pre-assembly.

Regards,

Martijn