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

Martin Aspeli optilude at gmx.net
Fri May 4 20:04:03 EDT 2007

(sorry, hit send before I finished)

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

Right. :)

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

Is that a bad way of developing general packages? Starting specific and 
factoring out generics?

Of course, that's a loaded question. But one thing which may happen is 
that the Grok community develop patterns and tools to make the 
re-factoring job easier.


More information about the Grok-dev mailing list