On 5 Feb 2007, at 11:50 , Chris Withers wrote:
Philipp von Weitershausen wrote:
Perhaps there's not a need for that separation in the Zope 3 core
with packages like zope.paste around...
Sorry, you lost me... there's what a need for what seperation?
What I meant: Since is we have things like zope.paste which work fine
as 3rd party packages already, perhaps the Zope 3 core just needs to
*support* this separation of server configuration and application
definition, but doesn't necessarily need to *do* it.
Yes, the publication in Zope 3 (which was written at an very early
stage with a lot of Zope 2 background) has a method
"getApplication", but all it does is return the root object. So
let's reflect that name in the utility.
Right, okay, my mistake, that's what I was referring to...
It just occurred to me that we could make those IRootObjectFactory
things named utilities. Then you cna register as many of them at
the same time and just choose which one you want using a switch
in, say, zope.conf.
Why named? If only so you can register many of them, then I call
yagni. Like a unix file system, a zope instance should only have
one root :-)
Sure. But the use of named utilities would make it a tad easier
because you wouldn't need ZCML overrides.
Let's say Zope 3 defines an IRootObjectFactory utility called
'zope.app.appsetup'. So, a default zope.conf would look like this:
# root-object-factory -- name of an IRootObjectFactory utility
# publication will use to create the root object.
# Default: root-object-factory zope.app.appsetup
Now, let's say you want to plug in a custom root object from, say,
SQL. You'd write your own IRootObjectFactory utility, register it
<utility factory="..." name="my.great.factory" />
and flip the switch in zope.conf:
Actual spellings may and probalby should, of course, be subject to
Zope3-dev mailing list