[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re:
Re: ANN: megrok.quarry)
gary at zope.com
Fri May 4 21:43:25 EDT 2007
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
>> 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.
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. ;-)
More information about the Grok-dev