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

[Martin Aspeli]

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

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[1].

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!

Martin

[1] see 
optilude.wordpress.com/2007/05/04/component-architecture-design-lessons/