[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:
[snip]
> 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
different.
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).
Regards,
Martijn
More information about the Grok-dev
mailing list