Grok component reuse in the Zope 3 world (was Re: [Grok-dev] Re: ANN:
gary at zope.com
Fri May 4 17:37:33 EDT 2007
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
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
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.
More information about the Grok-dev