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

[Martin Aspeli]

> 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 

I've never seen a package where this was doable, but I may be unlucky. :)

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

True, but again, making sure it doesn't get loaded by something else is 
a bit of a pain.

I'm sure you could manage this kind of pattern with grokkers too. The 
question is whether you want to.

> 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