Martijn Faassen wrote:
> Chris McDonough wrote:
>> Correct, if you're talking about using the Z3 publisher, although repoze.bfg
>> 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:
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
in the ZODB, allowing bfg to traverse the ZODB as the root. This is also the
domain of the "application" in terms of bfg.
Repoze-dev mailing list