[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re:
Re: ANN: megrok.quarry)
faassen at startifact.com
Sun May 6 15:28:36 EDT 2007
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
More information about the Grok-dev