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:

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.

- C

Repoze-dev mailing list

Reply via email to