[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re:
Re: ANN: megrok.quarry)
optilude at gmx.net
Fri May 4 19:32:37 EDT 2007
Gary Poster wrote:
> Grok's approach combats reuse outside of your community when it is
> used for anything other than an application. Grok feels like it is
> on the way to building another code vacuum--like Plone is, or at
> least used to be: code goes in from other projects, but little comes
We're trying not to be. :)
> I have two ideas on how to combat this.
> First, be vigilant about recognizing components that could be
> shared. Grok is about applications, not components. Make separate
> packages for the bits that we all (the Zope 3 community outside of
> Grok) can use. Make Grok packages that import from the general ones
> and add the Python-based glue in the grok-specific packages. Plone
> appears to be doing this now. Looks good to me. (I hope they do more!)
So do we. :)
However, Grok (from what I can tell) does have ways of registering
components, just not with ZCML. I mean, if an adapter is an adapter
because it inherits from grok.Adapter, or because it inherits from
object but has an <adapter /> line in configure.zcml, the CA won't care.
You still write:
from my.grokbased.package import ISomeInterfaceFromAGrokLikeThingie(
some_obj = ISomeInterfaceFromAGrokLikeThingie(context)
The thing which Grok does discourage a bit more, from what I've seen, is
to start with interfaces. I'm ambivalent about this. Martijn says "only
add interfaces when you really need them", which sounds sensible when
you're talking about applications near the top of the stack, but less
sensible when you are building something like a library.
> Second, when the first approach is inappropriate for whatever reason,
> consider putting the grok glue code in a separate module. That way
> someone can import your generally interesting code without depending
> on grok, or the grok approach. Perhaps someone else will even add a
> zcml file, and folks can choose to go the grok road or the zcml road
> for your package.
Grok packages still have a ZCML file, it just invokes the grokker, which
reads the other code and performs component registrations. I'm not sure
that's so different to ZCML reading lots of XML stanzas and configure
various components from these.
I think the difference lies in the culture and approach, though. If
you're building a specific application, over-generalising is probably
not productive and raises the bar for new users. I think Zope 3 heads
are sometimes guilty of over-generalising.
If you're building something general, then almost by definition that is
harder, and requires more thinking about interfaces and components and
their roles and responsibilities.
> In sum, I laud the Grok community's energy and desire to make cool
> Zope 3 technologies easier to begin with and use. But I encourage
> you to direct some of your energy to remembering that one of the cool
> Zope 3 ideas is component reuse. Don't code yourselves away from the
> rest of us: we want you around. :-)
Amen. It's insane how much more productive the Plone developers have
become since adopting Zope 3 design techniques. At the same time, we
worry that we're making an already large stack larger, but also
conceptually more complex to get into. There is a fine balance to be
struck, for sure.
> If these ideas are already prevalent in the Grok philosophy, and I'm
> spouting poorly informed tripe, I hope you at least recognize the
> goodwill in which this email was written.
:) and mine, I'm hardly a Grok developer or even user (though I'd like
to be), but I'm watching with interest. megrok.Plone!
More information about the Grok-dev