[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:00:35 EDT 2007
> 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
More information about the Grok-dev