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

Lennart Regebro regebro at gmail.com
Tue Apr 29 11:34:59 EDT 2008


On Mon, Apr 28, 2008 at 6:26 PM, Martijn Faassen <faassen at startifact.com> wrote:
>  five.grok is a web development framework. 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. :)

Right, but it is also true that with grok you try to install as little
of Zope3 as possible and not use the ZMI and so on. This will not be
possible with five.grok, so five.grok is an extension of Zope2, a
compatibility layer, as you mentioned, while grok  itself is
webframework.

>  I don't want to argue against people using a full import, but I also don't
> see it as a problem if they used an 'import as grok', as we're dealing with
> a strict subset. Either things work as expected with Grok, or they don't
> work at all.

We could call it five.grokcompat, and do from five import grokcompat
as grok. That would make it clearer that it is a compatibility layer.
The drawback is that we then has to make sure they really are 100%
compatible. :)

from five import almostgrokbutnotreally as grok. :)

On Tue, Apr 29, 2008 at 9:10 AM, Philipp von Weitershausen
<philipp at weitershausen.de> wrote:
>  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.)?

Well, because Five needs to do more than it does, but it doesn't,
partly because it's too hard to do. Five attempted to be a
compatibility layer so you could write modules that works under both
Zope2 and Zope3, but that hasn't happened, because we need to make big
changes to Zope2 to make Zope3 code run.

Since grok is a layer on top of Zope 3, this kind of compatibility
becomes much easier with grok than Zope, and it would be interesting
to explore that. Maybe it turns out to still be impossible, but it
should be much easier.

>  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.

Well, but Grok really is only basic components and views... so. :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64


More information about the Grok-dev mailing list