On 2 Feb 2007, at 18:15 , Chris Withers wrote:
Philipp von Weitershausen wrote:
As Jim pointed out in an earlier discussion [1], we would rather
like to separate server configuration from the application
definition (ZODB, logs, etc.).
That sounds like any work I do here will help...
- make twisted/zserver interchangeable through a zope.conf setting
Like Jim, I would rather like to see (at least the HTTP) server
definition thru something that's more general, such as paste.deploy.
I don't know paste.deploy and I don't have time or inclination to
learn it. However, any work I do will be aiming to make it simpler
to slot in different bits in different roles. What does
paste.deploy do?
It's a generic system that binds a WSGI application (such as the
zope.publisher) to a WSGI server (such as twisted.web2 or
zope.server). You can also register WSGI middlewares inbetween. See
http://pythonpaste.org/deploy/. Other Python web frameworks use it or
can at least use it. One of the big advantages of paste.deploy is the
easy definition of middlewares. Paste itself is a large library of
WSGI middlewares which features things like a funky live JavaScript
exception debugging middleware (the application raises an error and
the browser gets the full traceback, incl. a "command line" which
allows you to debug the code TTW, see http://mrtopf.blip.tv/file/
47128/).
Perhaps there's not a need for that separation in the Zope 3 core
with packages like zope.paste around...
I was toying with the idea of trying to have an IConfiguration
utility such that ZConfig could be switched out, is that what
you're talking about?
Not sure. Note that ZCML hasn't been loaded yet when main() is
executed and the application configuration is read.
I thik we can stick with ZConfig for now, even though Jim doesn't
like it... *wink* ;)
- refactor so that as much code as possbile is shared between
zope.app.twisted.main and zope.app.server.main
+1
I'd say that this should result in a general main() program that
*can* (but doesn't have to) read the application definition from a
zope.conf file,
Indeed.
and does server setup (at least HTTP) through a general framework
like paste.deploy.
Well, I'll try and make this code encapsulated...
I would assume that this also results in a separate configuration
file for paste.
Yay! More config files, just what we need ;-)
Well, if we'd use ConfigParser style config files for our application
definition, we could use one configuration file -- the one that
paste.deploy also uses...
- explore ways of seperating some of the publication concerns
+1
For one, I suggest factoring the whole root object issue out of
the publication (e.g. introduce an IRootObjectFactory utility
that, when called, will return the root object;
How about just making an IApplication utility, or is IApplication
too specific?
What *is* an "Application"? Sounds like a Zope2ism to me (the root
folder being called "application").
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.
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.
Philipp
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
