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

Philipp von Weitershausen philipp at weitershausen.de
Tue Apr 29 03:10:30 EDT 2008

Martijn Faassen wrote:
> Hi there,
> Philipp von Weitershausen wrote:
> [snip]
>>> * everything (both components and directives) works as a strict 
>>> subset of grok; you have adapters and such
>>> * grok imports these things into its own namespace.
>>> I think this usage is all right, as grokcore.component is considered 
>>> to be a strict subset of Grok. Using the name 'grok' here will lead 
>>> to relatively little confusion, and it *is* much prettier to use 
>>> 'grok.context()' instead of 'grokcore.component.context()'.
>>> Now we have five.grok.
>> I'm against calling it five.grok, to be honest.
> Why? It aims to provide the same API as Grok, after all.

Does it? I haven't read its README yet, so I don't know what the 
intentions of the authors are. Even if those were the goals, I don't see 
the point of replicating Grok in Zope 2.

Five in Zope 3 doesn't reimplement all of Zope 3 either. It just 
provides the most important and commonly used components. Perhaps I'm 
missing something, but why does five.grok need to do more than Five 
already does (not counting conventions over configuration, etc.)?

>>> This is a partial re-implementation of Grok.
>> No it isn't. five.grok is not a web framework. It's not integrated in 
>> any way. You may say I'm splitting hairs here (and you may be right), 
>> but conceptually I find grok and five.grok quite different. One is a 
>> framework, one is a library to extend another framework.
> five.grok is a web development framework.

Do you consider Five a web framework? I'd say five.grok is whatever Five 
is. To me, that's an extension to Zope 2.

> It doesn't work by itself, but 
> needs Zope 2 libraries (and Zope 3 libraries). Grok doesn't work by 
> itself too, it needs Zope 3 libraries. Anything else is a detail of how 
> things are installed. :)

But you don't install Zope 3 first, and then Grok. You install Grok. 
Zope just happens to be pulled in.

> Grok and five.grok allow the developer to do the same thing and aim for 
> API compatibility: write the same code and have the same thing appear on 
> their web page. The only difference is the underlying framework they are 
> integrated with (which is still largely the same, actually).

Again, I question both the existence of such goals (API compatibility) 
and the usefulness. I doubt that much of the community is looking for 
API compatibility beyond the basic components and views. The rest is 
Plone-specific stuff, really, which we already agree, shouldn't be 
called Grok in any way.

> Anyway, I'd say something like: "five.grok" uses Grok technology to 
> allow you to use the Grok APIs in a Zope 2 context.
>> I realize this is all about branding. But there must be a reason why 
>> Skodas aren't called Volkswagen, even though they reuse a lot of 
>> Volkswagen technology. It's so the Volskwagen brand isn't diluted.
> I don't think this dilutes the brand of Grok. I think our brand is clear 
> enough to use it in a Zope 2 context. If we came out and said they 
> needed to use some other name on Zope 2, I think *that* would cause some 
> confusion, as many Zope 2 developers are well aware of Grok already and 
> are looking to use this technology.
> I also think if we provide a library five.grok that works like Grok on 
> Zope 2, I think it'll be clear enough to people that this is not the 
> original Grok but a compatibility layer. This isn't that hard to explain 
> to people; this concept has been established quite thoroughly by Five, 
> after all.

True. And Five has a very specific name, and I think everybody 
understands it's just a compatibility layer.

> Anyway, we need concrete risks, either developer confusion or to the 
> brand, of calling the import 'grok' in the Zope 2 context.
> Calling it anything instead of 'grok' introduces a risk in my view. 
> Let's say they call it 'flurb' instead. Then suddenly people reading 
> Grok examples saying:
> class MyView(grok.View):
>    pass
> will have to know that they need to put in 'flurb.View' instead. I think 
> that's creating unnecessary mental work for people. To what purpose?

I think the mental work is minimal. Nobody objected when Five (due to a 
technicality) had to introduce a BrowserView base class. five.grok is in 
a way a special animal because it brings over some commonly used 
components to Zope 2. I still don't think that bringing over all of Grok 
is an important or even sensible goal. Therefore, five.grok will always 
be just a subset. And to be honest, probably a small subset (I suspect 
the future plone.grok will most likely be the rising star of Grok 
technology on Zope 2). But, who am I to predict the future :). Point is, 
it's not Grok and thus shouldn't trick the developer into thinking 
everything from Grok is available.

Making certain examples work both ways is an admirable goal which I 
completely support. The mental work translating namespaces is something 
developers can easily deal with. And if they end up doing it with an 
"import foo as grok", then so be it.

More information about the Grok-dev mailing list