On 3/4/09 1:07 AM, Chris McDonough wrote:
> Martin Aspeli wrote:
>> Chris McDonough wrote:
>>> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen.
>> Note that the "scolding" had something to do with you breaking Plone
>> trunk due to a transitive change in Chameleon, and the realisation that
>> from this point on, any package shared between repoze.bfg and Plone (or
>> anything else) that is configured with ZCML, will probably need to be
>> forked. We found a workaround with Chameleon, but not one that will scale.
> The fix is totally scalable and completely correct. Chameleon.zpt just does
> have any (real) ZCML anymore. Any package that has ZCML is, by definition,
> written for some framework as stuff that is meant to be overridden, otherwise
> wouldn't be written as configuration. ZCML is unlike code in this way. If it
> wasn't meant to be overridden, it would be in code.
> All packages which are meant to be maximally useful outside the scope of that
> framework should be split into two things: the library portion, then some
> portion that contains ZCML for gluing in to some framework that wants ZCML in
> some specific configuration.
When I read Martin's post, I had a similar reaction. Namely, that the
convenience of the Uberthing (Plone in this case) will always trump the
desire of packages trying to survive on their own for new audiences. At
the time of the configuration scolding, I remember thinking: there's
little interest here in Chameleon's goal to be bigger than Zope. "Keep
things convenient for us in Plone!"
Package sharing between repoze.bfg and Plone should not mean that BFG
gets dragged down, paying for things it specifically doesn't want to
eat. BFG never claimed to sign up for Plone's contracts.
I sense the logic of Chris's position: if the Zope Framework is as big
as every current use case in Zope2+Zope3+Grok+etc., with nine years of
accumulations on each (3 forms systems in one of them), then we're
missing the goal (IMO). We'll make life incrementally better for
ourselves, but we'll still scare off the folks who aren't after Uberthing.
Plone is going towards a smaller-and-smaller "core" that is only as big
as the manpower to do a great job at keeping it stable. Meaning, very
small. Hopefully the Zope Framework is a tiny little thing that pays
only for what it eats.
Hopefully the goal is to make a very good microframework (or even
better, set of libraries). If "you can't make the best configuration
language possible because one line of includes to get trusted adapters
is an unconscionable burden" is the rule, then I know how this movie ends.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -