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

[Lennart Regebro]

On 5/6/07, Gary Poster <gary at zope.com> wrote:
> replace "outside of zope" with something like "outside of the current
> expected usage" (i.e., I'm making your statement more general so it
> can be "outside of the zc, or lovely, or schooltool, or XXX projects
> that created it" and so on) then, at least on a quick skim, that
> sounds about right.

Right, then what you want to do is to use another set of zcml, and not
include the package in question in the normal zcml:ing. Which should
work just as well with grok, since you in both cases just do not
include the package in the package-includes.

> To be clear, the win of zcml, as I'm trying to present it, can be
> done without zcml--I gave the example of a separate Python file with
> a grok-like approach, for instance, as one of the possible
> replacements--but I'm arguing that having it done with Python
> alongside the Python of your implementation makes it more likely to
> break this win.

I don't think so, as that code doens't really do much unless it's
grokked. If for example subclassing from view.Grok had meant that a
view got registered then you would have a point. But now the view
class doens't get registered until you grok the module. So if you
don't want the view classes and otehr stuff to be registered, don't
grok the module.

But as Martijn said, it's good that you take this up, so it isn't
forgotten, and subclassing from grok.Something suddenly gets weird
side effects.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64