Re: [Zope3-dev] Re: zope.app.twisted.main?
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
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: 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. True. 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 that the # publication will use to create the root object. # # Default: root-object-factory zope.app.appsetup Why would this be in zope.conf at all? I would have thought just having a normal zcml setup for a single, global IRootObjectFactory utility would be fine... Also, why the factory? Why not just IRootObject? cheers, 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
Re: [Zope3-dev] Re: zope.app.twisted.main?
On 6 Feb 2007, at 09:59 , Chris Withers wrote: 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 that the # publication will use to create the root object. # # Default: root-object-factory zope.app.appsetup Why would this be in zope.conf at all? I would have thought just having a normal zcml setup for a single, global IRootObjectFactory utility would be fine... Well, actually, you can't register it through ZCML because ZCML knows nothing about the ZODB. zope.app.appsetup would have to instantiate and register such a utility if it finds a ZODB section in zope.conf, because the utility will have to know about the database. The point is that this is really hard to override. Overrides only work within the execution of a single ZCML tree. That's why I suggested named utilities. Also, why the factory? Why not just IRootObject? I guess just IRootObject is ok, the factory would have been a bit more generic because then you're not registering a specific root object for all times but could actually incorporate some logic into the root-object-finding-process. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: Why would this be in zope.conf at all? I would have thought just having a normal zcml setup for a single, global IRootObjectFactory utility would be fine... Well, actually, you can't register it through ZCML because ZCML knows nothing about the ZODB. Okay, how about the config parser registers the utility: from zope.component import provideUtility provideUtility(IRootObject,MyZODBRootThingy) Of course, I don't see any reason for the config parser to _have_ to do so... something just needs to register an IRootObject before the first publication gets instantiated, right? 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 / Also, why the factory? Why not just IRootObject? I guess just IRootObject is ok, the factory would have been a bit more generic because then you're not registering a specific root object for all times but could actually incorporate some logic into the root-object-finding-process. Why would you want to do that? There should be only one root, if it then wants to do interesting things, then either it can, or traversal adapters that start with it can. Why would you want any more complexity? cheers, 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
Re: [Zope3-dev] Re: zope.app.twisted.main?
On 6 Feb 2007, at 15:41 , Chris Withers wrote: Philipp von Weitershausen wrote: Why would this be in zope.conf at all? I would have thought just having a normal zcml setup for a single, global IRootObjectFactory utility would be fine... Well, actually, you can't register it through ZCML because ZCML knows nothing about the ZODB. Okay, how about the config parser registers the utility: The config parser (ZConfig) is generic and doesn't know anything about the component architecture. The main() program in zope.app.appsetup, which makes use of the zope.conf configuration, would have to do it. from zope.component import provideUtility provideUtility(IRootObject,MyZODBRootThingy) Of course, I don't see any reason for the config parser to _have_ to do so... something just needs to register an IRootObject before the first publication gets instantiated, right? 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. That's why I suggested we use named utilities because the we don't need to work with overrides.zcml. 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? 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. Also, why the factory? Why not just IRootObject? I guess just IRootObject is ok, the factory would have been a bit more generic because then you're not registering a specific root object for all times but could actually incorporate some logic into the root-object-finding-process. Why would you want to do that? Because I'm not sure how persistent objects behave in a global registry. 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. 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 :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
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? I thik we can stick with ZConfig for now, even though Jim doesn't like it... *wink* ;) I love ZConfig, so I'm okay :-) 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 :-) (anything else can be wired in below that...) cheers, 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
Re: [Zope3-dev] Re: zope.app.twisted.main?
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 that the # 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 like so: utility factory=... name=my.great.factory / and flip the switch in zope.conf: root-object-factory my.great.factory Actual spellings may and probalby should, of course, be subject to change. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
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? 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? - 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 ;-) - 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? the main() program, if it has a zodb configuration, would register such a factory that would talk to the DB; others could do SQL or whatever). Yeah, this is exactly what I'm after :-) cheers, 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
Re: [Zope3-dev] Re: zope.app.twisted.main?
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
