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

[Gary Poster]

On May 4, 2007, at 7:32 PM, Martin Aspeli wrote:

> 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. :)

No question.  Yay! :-)

...

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

Well, not just a library but a component.  But maybe we're saying the  
same thing.

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

Hard to deny...maybe especially in the early days but, of course, you  
never stop making mistakes ;-).  And as I believe you said in a  
subsequent email, often the best generalizing comes from writing  
concrete applications and factoring out the juicy bits after the  
fact.  But as you said, even that's a balance.

OK, better stop or I won't have time to reply to Martijn. ;-)

Gary