[Grok-dev] Re: on the name "Grok"
Philipp von Weitershausen
philipp at weitershausen.de
Wed Apr 30 04:54:43 EDT 2008
Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
>>> Hi there,
>>> Philipp von Weitershausen wrote:
>>>> 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.)?
> I always saw as the ultimate goal of the Five project the ability to run
> Zope 3 code unchanged in Zope 2.
So did I, in the beginning. I must admit that that goal has changed for
me, having appreciated the tremendous work that this entails (see next
> That goal hasn't been reached yet, but it's slowly moving forward nonetheless. (__parent__ based acquisition,
> for instance, thanks to you).
Yup, and it took three (!) years to get it stable and ready for merging.
Call it frustration or whatever, but I don't think I'll get much into
changing Zope 2 around anymore.
> Eventually I hope you can store a content
> object that's Zope 3 based in a Zope 2 container, and then forget about
> the rest of Zope 2 (except security).
There's also the publisher, which I suspect will likely be replaced by
repoze.zope2 though. In either case, it's not the Zope 3 publisher.
>> 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.
> Yes, you give the impression you're excluding quite a large bunch of
> stuff, but let's make a list of what the base classes are, right now, in
> Model - little use in Zope 2 until Z3 content can be stored (which I see
> as a future goal)
> Container - same as for model
> Site - should be useful in Zope 2.
> Application - should be useful if this can be mixed in with a Zope
> 2-based content class
I'd say that those four heavily depend on the kind of Zope 2 app and
framework (CMF, Archetypes, etc.). So not necessarily a goal for
five.plone, I'd say.
Yup, they're in grokcore.component.
These are done completely different in Zope 2 due to the different
publisher setup. We don't even have those working in Five yet (meaning,
pure HTTP views and XMLRPC views).
> template language pluggability
> resource support ('static')
> Traverser, 'traverse' method
> Indexes - can be used in conjunction with five.intid
Maybe, if somebody can be bothered to write a grokker that pokes ZCatalog.
> Permission - maps to Zope 2 permission
> Role - maps to Zope 2 role
These are difficult ones because Zope 2 stores and registers them
persistently, I believe. It's not impossible to do, just difficult.
> grok.require - view level security
> I'd say *most* of these look like something that the 'five.grok' project
> should make work in Zope 2. The model and container case don't make
> sense to port right away. The Indexes bit is hard to port, and I expect
> so might be the traverser support, the REST support and XMLRPC support,
> but that doesn't mean they wouldn't be useful to have.
Sure. I'm just being realistic, perhaps a bit pessimistic about how much
of this will actually be implemented. But you're right, that shouldn't
discourage anybody from setting larger goals and trying to reach them.
>> I think the mental work is minimal. Nobody objected when Five (due to
>> a technicality) had to introduce a BrowserView base class.
> True, though base classes don't play a fundamental role in Zope 3
>> 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.
> I'd like to you to elaborate on the subset argument, as above.
The list of base classes above was helpful and it indeed weakens my
argument. That said, Grok isn't all just base classes. Like Tim said,
it's a whole out-of-the-box experience. It's there to smoothen the Zope
3. five.grok just isn't the same thing. It's a bridge that, just like
Five, injects new life into an old platform, instead of being something
on its own (which Grok very much is). It doesn't have Grok's identity,
and calling it something with grok feels to me like it's stealing Grok's
identity in a way.
That said, I don't feel *that* strongly about it, at least not strongly
enough for me to carry on arguing on the basis of what seems to be
mostly intuition (about the identity of Grok) and past-experience (from
Five). If y'all think five.grok is a fitting name, then so be it.
More information about the Grok-dev