[Grok-dev] Re: on the name "Grok"

Martijn Faassen faassen at startifact.com
Mon Apr 28 12:43:41 EDT 2008

Brandon Craig Rhodes wrote:
> Martijn sees that we can now auto-detect and auto-register "Five"
> components, and he knows that this is best called "grokking" them, so
> he thinks that "five.grok" sounds like a fine description of that
> action. 

Actually it's a bit more subtle than that. Five components exist as 
equivalents of Zope 3 components. I.e. a Five view is very much like a 
Zope 3 view, with only things hacked up to make it work in the context 
of Zope 2 (things that thanks to Philipp's acquisition work can soon 
actually go away). A Five adapter *is* a Zope 3 adapter. Five is a port 
of Zope 3 things to Zope 2.

'five.grok', a port of Grok to Zope 2, can therefore be largely API 
compatible with 'grok'. Hopefully 'five.grok' can be an extremely thin 
layer eventually, hopefully only providing those bits that are really 

I argue that *that* can be called "grok" too. Where we have a 
'grok.View', there should be a 'five.grok.View', and where we have a 
'grok.Permission' there should be a 'five.grok.Permission' and where we 
have a 'grok.JSON' there should be a 'five.grok.JSON'.

The process of grokking anything else shouldn't be called "grok". 
Therefore I'm against something like "plone.grok".

> But Philipp objects because "Grok" is a cave man, not the
> name of a general technique, and no matter how convenient Django might
> become if it adopted the Zope component framework and used
> martian-powered auto-configuration, it would still not be Grok, nor
> would it run Grok web sites or understand Grok code.

Yes, and if Django adopted martian and grokcore.component it shouldn't 
start calling itself Grok, nor should its libraries be called 'grok' 
should they have some. But Zope 2 is very much *not* like Django, and 
five.grok is very much aimed at eventually being able to run Grok code 
(with just an import change).



More information about the Grok-dev mailing list