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] Test layers for zope.app.* packages
On Feb 5, 2007, at 11:41 PM, Fred Drake wrote: On 2/5/07, Baiju M [EMAIL PROTECTED] wrote: I have created zope.app egg two weeks back (http://svn.zope.org/zope.app/trunk/) I have used setuptools.find_packages function, so setuptools is a dependency. Should we need compatibility with distutils.core ? I suspect it's fine ok for an egg-supporting setup.py to depend on setuptools, though I'm wary of dependencies outside the Python standard library and our own code for basics. Using zc.buildout ensures setuptools is part of a buildout anyway, so I'll get over my own little hangup pretty quickly. Depending on a third-party egg is better than a vendor import (assuming that we don't need to customize it). We don't want to depend on anything with a viral license such as GPL. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Test layers for zope.app.* packages
Fred Drake wrote: On 2/5/07, Baiju M [EMAIL PROTECTED] wrote: I have created zope.app egg two weeks back (http://svn.zope.org/zope.app/trunk/) I have used setuptools.find_packages function, so setuptools is a dependency. Should we need compatibility with distutils.core ? I suspect it's fine ok for an egg-supporting setup.py to depend on setuptools, though I'm wary of dependencies outside the Python standard library and our own code for basics. Using zc.buildout ensures setuptools is part of a buildout anyway, so I'll get over my own little hangup pretty quickly. An egg should only *depend* on setuptools if it uses things like pkg_resources (e.g. for namespace packages). In that case even zc.buildout yells at you for not depending on setuptools: zc.buildout.easy_install: Develop distribution for kss.core 0.1dev-r37968 uses namespace packages but the distribution does not require setuptools. That setuptools are required for *building* an egg goes without question. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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
[Zope3-dev] Re: Test layers for zope.app.* packages
On 2/6/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: An egg should only *depend* on setuptools if it uses things like pkg_resources (e.g. for namespace packages). But there's no need to depend on setuptools for namespace packages generally; that's specific to namespace packages in the presence of zip_safe eggs. This is where I get (somewhat) antsy. That setuptools are required for *building* an egg goes without question. That I've never objected to; I don't want to duplicate that functionality. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ 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: Test layers for zope.app.* packages
On Feb 6, 2007, at 10:01 AM, Fred Drake wrote: On 2/6/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: An egg should only *depend* on setuptools if it uses things like pkg_resources (e.g. for namespace packages). But there's no need to depend on setuptools for namespace packages generally; that's specific to namespace packages in the presence of zip_safe eggs. I think it goes beyond that. In any case, there *will* be zip safe eggs. This is where I get (somewhat) antsy. I think you need to get over it. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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
[Zope3-dev] zope.mimetype / z3c.filetype
hello, is there any interest from the zope/z3c developers in unifying zope.mimetype and z3c.filetype? while the implementation of the packages is very different, the goals of both of them seem to be the same: to identify the contents of file-like objects and mark them with an appropiate interface. I don't know if there is some licesing or some other kind of political issues ( zope vs z3c ), but IMVHO it would be great if the two packages were merged. I'm not really a zope developer yet, but if the maintainers of those packs are interested, I could try to help with that. If a complete merge is not possible, then I think that at least the two groups should agree on a common interface so that users can decide which package they want to use: for example: z3c.filetype works on objects implementing z3c.filetype.interfaces.ITypeableFile and zope.mimetype works on objects implementing zope.mimetype.interfaces.IContentTypeAware It would be really good if both implementations (in case they are not merged) would work on some zope.IFileContents (example) interface and people could choose either one of the packages. comments? regards. luis ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Poll example fix
Hello in zope.app.form.browser.widgets.txt there is a Poll demo I could make it work but I had to do 2 modifications : replace content_factory=.poll.Poll with class=.poll.Poll in configure.zcml and I also had to remove: factory id=zope.app.demo.poll permission=zope.ManageContent / regards, Christophe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.mimetype / z3c.filetype
Luis De la Parra wrote: I don't know if there is some licesing or some other kind of political issues ( zope vs z3c ), but IMVHO it would be great if the two packages were merged. I'm not really a zope developer yet, but if the maintainers of those packs are interested, I could try to help with that. Interest is abundant; time and motivation are lacking. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
