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

Leonardo Rochael Almeida leorochael at gmail.com
Fri May 4 19:54:33 EDT 2007


I'm also just watching from the sidelines so far, so take my opinions
below with the large grain of salt reserved for those who haven't
actually delved into the technology and might be spewing B.S. for lack
of familiarity.

On 5/4/07, Martin Aspeli <optilude at gmx.net> wrote:
> Gary Poster wrote:
> [...]
> > 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.
>
> Grok packages still have a ZCML file, it just invokes the grokker, which
> reads the other code and performs component registrations. I'm not sure
> that's so different to ZCML reading lots of XML stanzas and configure
> various components from these.

The big difference is that, with a regular zcml package, if you don't
like it's configuration you can, hopefully, only <include > only the
zcml files inside the package you need or at the worst case (when
there is a single monolitic zcml file). Copy it to your package and
replace the parts you don't like.

With grok, as far as I can tell, it's an all or nothing. You might be
able to grok only some subpackages of a certain grok package, but
that's it.

This means that the configuration granularity of grok is necessarily
at the package level, whereas standard zope3 granularity is as fine as
you are willing to copy huge swaths of configuration :-)

Martin is right in that for someone that's just starting an app, the
whole generality that zcml allows might not be that much useful at
first, but the grok approach  means that someone who's starting to
realize the more general parts of his application will have to factor
them out into separate packages.

In the end, that might be even a good thing, but it certainly make
working towards generality a bit harder, which is why I'd like to see
things like grok tags. If I understand it correctly, that would allow
naming certain grok declarations for selective inclusion by third
parties, which would make it simpler for a coder to just sprinkle some
tags in order to make his code more fine grained from the
configuration/policy/grokking point of view (did I get that right)?

Cheers, Leo


More information about the Grok-dev mailing list