[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re:
Re: ANN: megrok.quarry)
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 :-)
> 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