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 zope.app.appsetup,
which makes use of the zope.conf configuration, would have to do it.
...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...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
