Tres Seaver wrote:
>>> repoze.bfg takes yet another approach.
>> I'm sure there are new ZCML directives it introduces, but it also forked
>> the current ZCML directives that are in zope.component for basic
>> component registration, to reduce its dependencies. Perhaps that fork
>> can be undone if we improve the way we break things down (to anticipate
>> what you're saying below).
> The fork is not merely to reduce dependencies: BFG also wants to
> eliminate the requirement that there be "one global component registry
> to rule them all," which is pretty deeply embedded in zope.component.
> Breaking that assumption allows multiple BFG apps to run in the same
> process, with incompatible components registered, without any chance
> that they will step on each other's toes.
Cool, I hadn't realized that. I think it would be useful to fold that
support into the Zope framework itself too.
> "Reusable configuration" is a bit of an oxymoron: if everybody *must*
> use the configuration, then it isn't configuration at all, but software.
> I think, however, that this discussion is about where to put the "meta"
> bits (the parts which actually implement ZCML directives), rather than
> rehashing the library vs. application problem (where to put the
My interpretation of what Hanno said was that he was talking about
reusing the implementation of configuration. I.e. repoze.zcml might
define an action that zope.componentconf might use in the implementation
of its own actions. Anyway, no matter what Hanno said, I think that is
an interesting area to explore. Grok and Five both want to reuse as much
of the underlying action implementation in the Zope framework as possible.
> I would argue that putting any ZCML-related implementation in a separate
> package from the zope.component core would be a win, at least from the
> perspective of clarity and dependencies.
It might be that the core implementations of actions a-la repoze.zcml
could be moved into zope.component. repoze.zcml could then become a
smaller package that simply registers the directives themselves for
We could then have something that builds on this (and zope.security) to
implement the directives that zope.component now implements.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -