Philipp von Weitershausen wrote:
Okay, how about the config parser registers the utility:

The config parser (ZConfig) is generic

Well, it runs of a schema which uses handlers specific to the project, so I don't see what your point is here...

the component architecture. The main() program in, which makes use of the zope.conf configuration, would have to do it. sounds like Zope 3's ZConfig schema creates an inert source of information, unlike Zope 2's, which instantiates things as it parses the config. Is that the case?

Right, but the whole point of factoring it out to a utility is to gain the ability to override things. If it's registered using z.c.provideUtility(), it'll be hard to impossible to override it using overrides.zcml.

True, but if this happens in parsing zope.conf, you don't want to be able to change it later...

That's why I suggested we use named utilities because the we don't need to work with overrides.zcml.

I'm still struggling with why they need to be named, no doubt I'll find out why if/when I make a start on this ;-)

If so, what bad things could happen if the zodb sections in zope.conf were made optional and a later zcml statement provided the utility?

<utility factory="myIRootObjectProvider" />

Yeah, but how would you implement myIRootObjectProvider w/o having access to the ZODB?

I'd envisage myIRootObjectProvider would be the thing which opened the zodb...

You don't know which ZODB you're going to get the root object from because that's decided *at runtime* in the main() program by reading zope.conf.

I thought you said the ZCML was processed after the main() stuff?

Because I'm not sure how persistent objects behave in a global registry.

I'd imagine the root would just be a factory that opened a new connection/etc on traversal, or when it was requested by the publication, or some such...

Right now in the Zope default publication, the root object is gotten *after* opening the DB. If we'd register the (persistent) root object in the global registry, it might exist w/o any ZODB connections open. Not sure if that's every going to occur, or if that's going to be a problem, etc.

I would hope to keep the semantics of getting the root object after opening the db in the same way...

Anyway, I think I've tried to give as many pointers as I could. I'm sure some of the things discussed here will come up when you'll implement this :).

Yep, I think it's time to start cutting code... eep...


Simplistix - Content Management, Zope & Python Consulting

Zope3-dev mailing list

Reply via email to