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 > not > 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 > it > 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. --Paul _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )