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

[Martijn Faassen]

Gary Poster wrote:
> 
> On May 6, 2007, at 1:09 PM, Martijn Faassen wrote:

> I'll again try to be brief, since I've accomplished my goal, as 
> mentioned in my other email.

[snip my long explanation]

> I see.  Thanks for the explanation.
> 
> It still doesn't negate the argument for separate packages when 
> appropriate, my first suggestion in the original email. :-D  

Yes, makes sense. So far, I think most of the work discussed is not 
about making new features but about trying to increase the ease of use 
of what's already there in Zope 3, i.e. Grok's mission and not really 
applicable outside of Grok.

This will change - for instance, as mentioned briefly before, I'm 
sitting on one package Jan-Wijbrand Kolman and I developed that has 
little to do with Grok, and that I'd like to release but can't really do 
yet. Last friday before this discussion started, I was actually 
discussing why not with the client that this package was developed for.

Of course it'd not be hard to rewrite this package so it'd use ZCML, but 
I'm using it as my test-case for this particular problem, so I won't. :)

> This is 
> similar to one of the distinctions we made in Zope 3  between zope.* and 
> zope.app.*: "put your generic code, without much or any configuration, 
> in zope.*, and the configuration stuff in zope.app.*".  While we have 
> moved away from doing this strictly, I believe the rule still has some 
> merit, as long as it is not applied with *too* much consistency ;-).

No debate that generic code is good. It's part of the Zope 3 philosophy 
I certainly don't want to give up. I think in general the idea is:

* reusable Python code independent of Zope 3 is best

* if that isn't practical, write generic code dependent on Zope 3.

* if that isn't practical, write this code as part of a larger application

Of course often you start at the bottom. With Martian for instance, we 
first wrote code that just did what Grok needed to do, then made it more 
generic but still tied up to Grok, and now we're spinning it off into 
its own Python library.

Starting at the bottom tends to make for better components as you 
actually learn what kind of generic functionality is really needed. This 
is why it's important we can do this with Grok-based code with a minimum 
of barriers.

Regards,

Martijn