Jim Fulton wrote:
Here's what I'd like to see:
1. Separate server definition from application definition. They are
way too interwoven now. I'd like to see us move to Paste Deploy (or
something based on the framework it defines).
Is this the seperation of "what objects are being served" from "what
protocols are being served" that I mentioned in my other reply?
Someone. More it's a separation of the server definition from the
I suppose, you would like to do the server definition thru something
like paste.deploy (allowing us to let the assembly currently done by the
two main programs be done generically).
What would the application definition be? Still ZConfig?
(Note that in my original reply to ChrisW, I tried to be pragmatic. Of
course, if ChrisW has the resources to go into this refactoring, by all
means, let's do it).
In my dreams, it'd be great if I could just wire in a different
IApplication utility to get the root of the object tree and just leave
the zodb section of zope.conf empty. How hard would that be to achieve?
There are two parts of your question. Making it simpler to plug in a
different application root, and dealing with ZConfig.
Ironically, the current publication object doesn't make much use of the
component architecture. This is a historical accident. I'd like to see
a different publication object that did use the component architecture
In order to implement a simpler security mechanism for grok, we had to
re-implement every single publication (though of course subclassing was
still possible, but we had to create a new variant of every publication
class). That shouldn't be necessary.
WRT ZConfig. I find myself fighting ZConfig a lot. If I were to write
a new main program, I wouldn't use it at all. In fact, I would probably
use a much simpler model like that used by Paste Deploy. I really don't
want to have a ZConfig argument though. I got out voted on that last
year. If you do want to use ZConfig, you could simply use the
application schema defined in zope.app.appsetup rather than the ones in
the server packages.
I think the ZConfig argument was largely due to misunderstandings. I
would be surprised if people really cared whether to Zope used
ConfigParser or ZConfig (except Fred, perhaps ;))
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
Zope3-dev mailing list