Grok component reuse in the Zope 3 world (was Re: [Grok-dev] Re: ANN: megrok.quarry)

[Gary Poster]

On May 4, 2007, at 4:20 PM, Martijn Faassen wrote:

> David Pratt wrote:
>> Hi Kevin. I am interested in which grok components will be able to  
>> be to be used directly in Zope 3 so that security within the Zope  
>> 3 app remains explicit.
>
> Right now Grok doesn't support this use case, but we're actively  
> doing work on making this possible. That is, grok is going to be  
> split up in various sub-components, some of which will be safe to  
> use with Zope 3. grok will still remain grok however - the public  
> API of grok won't be affected, it will just depend on various sub- 
> packages which can also be used separately.
>
> After this refactoring it should be possible to make many grok  
> extensions depend on grokcore.component. This doesn't mess with  
> security (grok itself does that) but implements basic grokkers like  
> adapter registration, etc.
>
> Before this is done a lot more work will need to be performed,  
> however. I myself have started work on martian, which aims to  
> abstract about the basic grokking logic into a generic library that  
> doesn't need zope (perhaps just zope.interface). Things like  
> grokcore.component can then, hopefully, directly depend on martian.  
> After martian is complete we need to start moving various grokkers  
> outside of the grok into the grokcore packages.
>
> So the answer is, not right now. In time this will happen. Help is,  
> as always, appreciated. :)


This reply crystalized a concern I have been feeling.

The grok approach is throwing out zcml, at the expense of...zcml.

There actually was a reason why we wanted something like zcml-- 
something *not* in the Python file.  The reason was that we wanted to  
make it possible to reuse Python without being forced to reuse  
configuration.  We wanted components.

Whatever its failures--perhaps in spelling?--zcml appears to have  
accomplished this. We, the Zope 3 community, are growing little  
microcosms of code reuse.  ZC, Lovely, z3c (Roger and Stephan,  
largely?), Gocept, Canonical/SchoolTool, Martijn in the "hurry"  
namespace, and others have grown their own worlds of software that  
are being mixed and matched and used as components by a variety of  
projects.

I argue that a significant contributor to this flexible ecosystem is  
the fact that the vast majority of this code uses ZCML--stuff outside  
of the Python files--for configuration and glue.

I haven't looked at megrok.quarry, but I expect it is interesting,  
like other projects in the grok world.  It also sounds like it is, in  
part, general--like it has code that other projects might want.  Why  
is it grok code?  Perhaps megrok.quarry is a bad example, but I read  
about catalog conveniences, view conveniences, and other interesting  
things on this list.

Grok's approach combats reuse outside of your community when it is  
used for anything other than an application.   Grok feels like it is  
on the way to building another code vacuum--like Plone is, or at  
least used to be: code goes in from other projects, but little comes  
out.

What Martijn describes in this reply sounds like it might be in the  
right direction.  But IMO and AFAICT it is still insufficient.

I have two ideas on how to combat this.

First, be vigilant about recognizing components that could be  
shared.  Grok is about applications, not components.  Make separate  
packages for the bits that we all (the Zope 3 community outside of  
Grok) can use.  Make Grok packages that import from the general ones  
and add the Python-based glue in the grok-specific packages.  Plone  
appears to be doing this now.  Looks good to me.  (I hope they do more!)

Second, when the first approach is inappropriate for whatever reason,  
consider putting the grok glue code in a separate module.  That way  
someone can import your generally interesting code without depending  
on grok, or the grok approach.  Perhaps someone else will even add a  
zcml file, and folks can choose to go the grok road or the zcml road  
for your package.

In sum, I laud the Grok community's energy and desire to make cool  
Zope 3 technologies easier to begin with and use.  But I encourage  
you to direct some of your energy to remembering that one of the cool  
Zope 3 ideas is component reuse.  Don't code yourselves away from the  
rest of us: we want you around. :-)

If these ideas are already prevalent in the Grok philosophy, and I'm  
spouting poorly informed tripe, I hope you at least recognize the  
goodwill in which this email was written.

Gary