Martijn Faassen wrote:
Hey,
Chris McDonough wrote: [snip]
Correct, if you're talking about using the Z3 publisher, although repoze.bfg is based on zope.component and zope.interface internally.
I wasn't primarily thinking about the publisher, more about such things like existing utilities, events, existing content types and so on.
Most of those would work. We don't implement local site managers, but we do use a normal component registry, so if you've got a global utility that you'd like to use, you'd just put its registration into the configure.zcml, make sure you had the right package on the filesystem to handle that registration. ... Speaking of site managers, if you'd like to be able to use more than one separtely-configured grok application in a process (given that you can't right now because the global registry is a singleton), you might want to steal this hack. I myself stole the idea from Stephan's z3c.baseregistry: http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/registry.py Sending events would of course work. We don't have any event *listeners*, of course, so it would be pointless to send, e.g. object events. That said, "contenty" stuff is not really the job of repoze.bfg, but of a higher-layer framework. repoze.bfg is about traversing the content graph and publishing views and templates. Everything else is the domain of the "application". Existing content types would work to the extent that you'd just use them as data in the ZODB, allowing bfg to traverse the ZODB as the root. This is also the domain of the "application" in terms of bfg. - C