[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re:
Re: ANN: megrok.quarry)
Martijn Faassen
faassen at startifact.com
Fri May 4 21:40:11 EDT 2007
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
More information about the Grok-dev
mailing list