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

Martin Aspeli optilude at gmx.net
Mon Apr 28 16:16:16 EDT 2008


Martijn Faassen wrote:

> The general rules:
> 
> * ports to different platforms can be called 'grok'

+0.5 - or maybe something grok-derived?

> * strict subsets of Grok should be called 'grokcore.<name>'. When using 
> them, the user can use the word 'grok', in something like 'import 
> grokcore.component as grok'. That said, this only works if you use only 
> a single subset at the time.

I think that's a bit pointless (but of course entirely up to the code 
that uses Grok, you can't stop me from doing from plone.app.portlets 
import martians as grok).

I think Grok-the-framework should have a convenience import called 
'grok' that lets you get the most common stuff out of one namespace.

> * things that introduce new base classes or directives shouldn't be 
> called 'grok'

Absolutely.

> * imports should behave like normal python imports; no magic registry 
> behavior here.

No question about this.

I think there's one point missing here, though: "Grok" is a web 
framework, and as such a "brand name". It absolutely deserves to keep 
that, and I don't think we should dilute it with other things.

However, Grok is also about defining conventions and "syntax". You do:

class Foo(grok.Adapter):
     ...

and Foo is now much more than a class - the base class has some semantic 
meaning, and it alters the behaviour of the thing that's using it in an 
explicit, profound way.

This pattern deserves to live beyond Grok and into Zope 2, and Plone, 
and other places.

Unfortunately, Python doesn't really afford us too many syntactic 
options here. If we had class decorators, things would be easier:

@Adapter
class Foo:
     pass

but we don't.

I think we need to come up with a convention that means it's clear what 
base classes, descriptors and functions have these magic "grokking" 
behaviours, and apply them across things that use Grok's patterns and 
machinery.

To a certain extent, we already have a name for something like that - 
"martian". Hence, perhaps we should instead have:

  from plone.app.portlets import martian

  ...

  class MyPortlet(martian.Portlet):
      martian.name('foo')

and so on.

In the above, note:

  1) I'm using "martian." as the prefix for things that have 
grok/martian-like behavour. Another option may be a common naming 
format, e.g. calling it an "MPortlet" and an "MAdapter", though I think 
that looks quite ugly.

  2) I'm presuming that the grokkers/martians for Plone portlets live 
close to the package that defines their semantic meanings: 
plone.app.portlets in this case. "Portlets" only exist in the context of 
plone.portlets/plone.app.portlets.

  3) Some grokkers/martians are really representions of basic Zope 3 
concepts like adapters and utilities. Perhaps they deserve some more 
common namespace that's usable both from Zope 2 and Zope 3 in a simple way.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book



More information about the Grok-dev mailing list