[Grok-dev] Re: on the name "Grok"
faassen at startifact.com
Tue Apr 29 05:43:17 EDT 2008
Philipp von Weitershausen wrote:
>> Do you really prefer people write this?
>> class MyAdapter(plone.easyapi.Adapter):
> Sure. Or they can simply use it from grokcore.component. The point of
> "plone.easyapi" surely isn't to provide solely adapters and utilities
> but primarily other types of components.
Yes, the equivalents of the components in 'grok'.
>> This sounds terrible to me. Suddenly people have to mentally translate
>> all the examples that already exist for Grok.
> That's the last of my worries, really.
Well, it either needs a somewhat silly line on top examples ("in Zope 2,
instead import 'import plone.easyapi' instead of 'import grok'), or a
duplication of examples people can't see very quickly are related.
>> Do you really think people won't be writing: 'import plone.easyapi as
>> grok' anyway? That's certainly what I'd be very much tempted to write
>> if I wrote any examples for Zope 2!
> Sure, but you're not writing a Grok application. You're writing some
> extensions to Zope 2 (if you were using five.grok). If you were using
> plone.grok, you'd actually be writing completely new components that
> Grok didn't have, so here (and it seems we agree on this), using the
> 'grok' name makes even less sense.
I don't think plone.grok is part of this debate; I see this as an
entirely separate problem. I agree that plone.grok adds new components
that Grok doesn't have, and that's why its name is out of the question.
'five.grok' if it aims to replicate the Grok experience I think is named
>> Why can't Zope 2 have a package 'five.grok' that aims to provide the
>> same API as Grok does?
> Sure, Zope 2 could have it. Maybe we're not clear on what the goal of
> five.grok is. I certainly don't see why it needs to replicate Grok all
> over. If you start from scratch, you could just as well use Grok. If you
> don't, then you're extending a legacy application. But then you don't
> need (and possibly can't use) all of Grok.
I think a very significant chunk of what's in Grok is directly relevant
to Zope 2. What in Grok *doesn't* below in a five.grok? Models, I can
see - even though that might eventually change. I can also see that
making 'grok.Indexes' work is a bit of work (though there is intid
support for Zope 2 now, so it shouldn't be that crazy).
> I'd say in 99% of the cases
> you just want views and perhaps viewlets.
>> If we are careful to refer to this as 'five.grok' or 'Grok on Zope 2'
>> I think we can tolerate the minimum confusion this should cause.
>> Should we be that much afraid of Zope 2?
> I'm not afraidof Zope 2, I'm afraid we have different understandings of
> the word "Grok". 'Grok on Zope 2' is mostly about using a small subset
> of Grok's technology.
I don't see this as a small subset of the developer's experience.
> But Grok is so much more than just the technology.
> It's also about the smooth ride (convention over configuration, KGS-like
> version pinning, buildout scaffolding, etc.). Sure, we can replicate all
> that for Zope 2, but what's the point? I think "Grok on Zope 2" has much
> less ambition than our Grok (on Zope 3), and that's ok because like Five
> itself, it's just meant to bring legacy apps up to speed.
Yes, it has less ambition, but I'd say it goes for the same APIs.
>> What if we ever get so far that "import grok" works on Zope 2 without
>> modifications? Do we tell people that 'plone.easyapi' is now Grok
>> after all?
> If making "import grok" work on Zope 2 is your goal, then I think we
> have very different goals.
It's not my goal, as I'm not a five.grok developer. But if I were a
five.grok developer, that'd be the ultimate goal I'd be aiming for. I
wouldn't expect to reach it for a long while, but I'd want everything
else to work as easily as 'grokcore.component'. Probably requires
changes in Zope 2.
>> I think you make a good point in that we should be clear that "Grok"
>> is what we have created and develop here. If you are going to make a
>> Grok for Zope 2, that shouldn't be referred to as "Grok" unless the
>> context is unambiguous, but as "Five Grok" or something like that.
> Or, as Brandon suggested, using the *verb* rather than the noun, e.g.
> "Grokked Five" or "Grokking Zope 2" or whatever.
Well, I don't think we're really talking about the verb here. We're
talking about the API and developer's experience, base classes and
grokkers that have the equivalent effect in the Zope 2 context.
What's called "plone.grok" is about grokking Plone components, and I
think the word 'grok' (or variations such as the verb) should simply not
be used in the package name there, though "grokking" is of course a nice
descriptive word of the process. I hope that can be folded into a bunch
of base classes that are as much a part of their modules as the base
classes are now. (neither do I think 'martian' should appear there, by
More information about the Grok-dev