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

[Martijn Faassen]

Leonardo Rochael Almeida wrote:
> 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:
[snip]
>> 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.

This is true. It also doesn't happen a lot. I think there are two 
reasons why you typically don't do this when reusing a package:

* you need to know the insides of the package you're reusing pretty well 
in order to rewrite its ZCML.

* having rewritten ZCML maintained outside of the package means you have 
a maintenance burden. Each time the package gets updated, you may need 
to update the ZCML.

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

That's true at present. We're considering two mechanisms to solve this 
problem:

* grok.skip(), which can be used to skip component registrations. Can be 
used outside of a package. This would be somewhat similar to the 
'rewriting ZCML' scenario, with the same benefits and problems.

And the other mechanism, which you already mention:

 > 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)?

Yes, I think you got that right. :)

* grok.tag() which can be used to tag component registrations. This 
would be used by the package maintainer. Particular types of 
registrations that may need to be either turned off, or selectively 
turned on in a reuse scenarios are tagged. The package reuser would then 
go and say 'give me all registrations in these tags' or 'give me all 
registrations, except for this tag'.

I expect evolving this will take a while, as I don't consider this very 
urgent - I don't recall reusing a Zope 3 package yet without reusing its 
ZCML. :) I'm therefore wondering how often this occurs in practice. 
Martian should however make infrastructure like this easier to implement 
as it makes the grokking infrastructure very explicit.

Regards,

Martijn