[Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9 Feb 2007, at 11:03, yuppie wrote: Taking this into account, how should the five.localsitemanager thing be packaged? Maybe we can use the same pattern as TextIndexNG3: The Python package is shipped in a 'src' subdirectory of the product. The product's __init__ adds 'src' to the sys.path. The code could check if five.localsitemanager already exists (e.g. in a Plone distribution) and modify sys.path only if necessary. This is a hack, but maybe good enough as a temporary solution for CMF 2.1. That's certainly good enough for me. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFzEj1RAx5nvEhZLIRAkBlAKCfKlATCPmles60ihE3XAhDYWxd0QCfe8G8 tPqM6K8fjpnx7XVCMbP2aik= =kmtO -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 9 Feb 2007, at 11:03, yuppie wrote: Taking this into account, how should the five.localsitemanager thing be packaged? Maybe we can use the same pattern as TextIndexNG3: The Python package is shipped in a 'src' subdirectory of the product. The product's __init__ adds 'src' to the sys.path. The code could check if five.localsitemanager already exists (e.g. in a Plone distribution) and modify sys.path only if necessary. This is a hack, but maybe good enough as a temporary solution for CMF 2.1. That's certainly good enough for me. I was about to suggest that: create a pure five.localsitemanager package for the package zealots and make a product that simply puts it on sys.path. I don't think resorting to relative imports is an option. I personally think Python 2's import semantics are pretty much fubared and I can only recommend to always use absolute imports. Also, whatever we create now will have to live under Seaver's law (Persistence means having to say I'm sorry) because five.localsitemanager will obviously have persitent objects (the LocalSiteManager implementation, which is a subclass of PersistentComponents). Anyway, yay on the consensus for CMF 2.1! -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: Let's get this discussion back from generic pie-in-the-sky to the simple situation where we just need this one package integrated into CMF 2.1, and quickly. +1 Wichert wants a Plone 3 beta very very soon, there is no time to switch the CMF to any other packaging/buildout mechanism before that. What happens on the trunk after the 2.1 branch is cut, I don't care. I do care about getting the 2.1 beta out quickly. All that's missing is merging the tool/utility stuff, which depends on having this new component registry. Taking this into account, how should the five.localsitemanager thing be packaged? My preference would be to ship CMF 2.1 as two tarballs - one for lib/python and one for Products, or one tarball containing Products/* and lib/python/* (i.e. to be extracted into the Zope instance root). If that's unacceptable, Rocky can make localsitemanager use only relative imports and thus function as both a product and a package, though I don't know if anything needs to refer to Products.localsitemanager, which in turn makes it painful to use it as a regular python package. Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: I'm not convinced that anything which is this tightly coupled to Zope needs to be a package, rather than a product. I don't think the package zealots get the fact that purity is not a win if we have to distort the rest of the application to satisfy it. Amen to that. I guess you could argue that if it's fairly close to Zope 3, then it should follow Zope 3's conventions. :) Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Feb 2007, at 01:58, Philipp von Weitershausen wrote: Eggs contain Python packages. How you deploy the Python packages is your choice. If you like copying or symlinking, fine. And, heck, you can still symlink your products to Products. Nobody's getting rid of Products. But please-oh-please let us start developing new things in regular packages so that we can a) make use of the tools provided to us by the greater Python community b) ease other Python programmers into Zope (no more weird Products, no more Zope stinks, no more Zope is its own universe). Some of us *like* reaching out. c) make things easier for *ourselves* (being able to test a simple Python package outside the context of a full-blown Zope instance is a tremendous win). I won't grace the uncalled-for sarcasm with an answer. You misunderstand my point. I simply don't want the existing dead-simple way of creating quick sandboxes be replaced by some mechanism where I need to start writing configuration files or learn some wondrous framework, just because it's been decreed the technology du jour. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFyaJmRAx5nvEhZLIRAkP2AKCwuDw3p9xi4Ccb8qQz/aGHj8AxbQCdH0Mv aIFSe8x70xacA0n6qb3oSNg= =e0un -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: I won't grace the uncalled-for sarcasm with an answer. You misunderstand my point. I simply don't want the existing dead-simple way of creating quick sandboxes be replaced by some mechanism where I need to start writing configuration files or learn some wondrous framework, just because it's been decreed the technology du jour. Would you be ok if you had a tarball or svn:externals to place blanket into lib/python instead of Products? That's achiveable now (you end up with lib/python/Products/CMFCore etc, but potentially also lib/python/five/localsitemanager or lib/python/plone/memoize if you guys wanted to use that). In terms of sandboxes, I agree that zc.buildout (which is the only one of the tools that uses a config file) can be a bit heavy for quick prototyping (but equally useful for tightly controlled, repeatable deployments, potentially shared by multiple developers having identical local sandboxes). Any workingenv-based solution will be pretty quick, though. The example I showed for 'ploneenv' is really just calling workingenv and installing the Plone egg. If there was a CMF egg then (a) Plone would just depend on it and (b) any dependencies (products or otherwise) that this egg depended on would be automatically fetched. Of course, if you have it once, it's a single directory (or zip file), that you could lump into lib/python directly. At the moment, Zope isn't terribly happy running tests out of eggs that are deployed as eggs (as opposed to ones you may copy/symlink to lib/python directly, which it runs fine). Basically, you need to do this: $ bin/zopectl test -m my.package --test-path src/my.package presuming the egg is in src/my.package. Various people are getting annoyed by this, so I expect it'll be fixed fairly soon, possibly by using Zope 3's testrunner directly (but it may require a bit more un-majikifying of the Products namespace first). Martin -- View this message in context: http://www.nabble.com/Tools-as-local-utilities-tf2245411.html#a8843224 Sent from the Zope - CMF list2 mailing list archive at Nabble.com. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 7 Feb 2007, at 01:58, Philipp von Weitershausen wrote: Eggs contain Python packages. How you deploy the Python packages is your choice. If you like copying or symlinking, fine. And, heck, you can still symlink your products to Products. Nobody's getting rid of Products. But please-oh-please let us start developing new things in regular packages so that we can a) make use of the tools provided to us by the greater Python community b) ease other Python programmers into Zope (no more weird Products, no more Zope stinks, no more Zope is its own universe). Some of us *like* reaching out. c) make things easier for *ourselves* (being able to test a simple Python package outside the context of a full-blown Zope instance is a tremendous win). I won't grace the uncalled-for sarcasm with an answer. Jens, I didn't mean to be sarcastic. Sorry if that came across wrong. You misunderstand my point. I simply don't want the existing dead-simple way of creating quick sandboxes be replaced by some mechanism where I need to start writing configuration files or learn some wondrous framework, just because it's been decreed the technology du jour. I understand and believe it or not, I also sympathize :). The good news is that it's still possible. After all, the initial argument of this thread wasn't that we wanted to eggify or buildoutify CMF, but that we wanted to introduce standard Python packages as possible dependencies. Such packages only have to be on the PYTHONPATH, e.g. put into INSTANCE/lib/python. How they end up there is up to you. As said, symlinking, copying, etc. still works. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Feb 5, 5:40 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 5 Feb 2007, at 19:43, Rocky Burt wrote: On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). Not knowing any better I was assuming there'd be a Zope 2-style product, which we could pull in as a SVN external? Hm... well, as long as I avoid absolute imports in five.localsitemanager there's no reason it couldn't be included into a CMF product (perhas CMFCore ?) via svn:externals. That's not something I'm particularly fond of but I'm not against it. But as time moves on this is going to become more and more of an issue for CMF (code that isn't expected to live in Products/). - Rocky ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Feb 6, 5:45 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: Right now all you need to do to install CMF is to link all the contained folders into the instance Products folder. I'm somewhat averse to complicate that process. I understand the sentiment and we dealt with the same thing for Plone. I know at one point someone (I think Philipp) suggested that we could actually place the products we have into lib/python/ instead of the Products/ directory for Plone by using an empty namespace package for Products (so CMFCore would become lib/python/Products/ CMFCore). I haven't tested this myself but if it's ease of deployment you're looking for, perhaps extracting everything there would do the trick. Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF - Rocky ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
Am 06.02.2007 um 22:14 schrieb Rocky: Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of regular python code but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFyRMtRAx5nvEhZLIRAvlnAKCT0RM5RZ4gs3wfoLxrDZ/wT81PvwCeNMdk GZVIDO16jeYQV6XSKRTCJZk= =//MN -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Ever heard of sys.path? Sorry, I don't want to waste bandwidth on the CMF list on a flame war. Eggs are there and I will have to learn to live with them but I don't have to like them. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Meanwhile, the rest of the Python world came up with something better and more widely accepted. Until Zope 2.10 and Plone 3, the whole Plone and CMF stack depended on no library that was re-usable outside of Zope (apart from PIL, and unless you count parts of Zope 3 shipped with Zope 2.8+). Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Works fine for mxODBC Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. For Plone 3 development, we have two solutions (depending on which one you prefer). I'll explain them briefly to give you a flavour of how they may work. The first is called ploneout, and is a zc.buildout. We had to create a couple of recipes to play nice with Zope 2, but these would work fine with CMF. Basically, all ploneout is, is a particular buildout.cfg that references Plone's eggs and products via svn:externals, in development mode (as opposed to as dependencies). This also downloads builds Zope 2.10 and all other dependencies, in a single command (though if you want to point to an existing Zope install to save space, you can). $ svn co https://svn.plone.org/svn/plone/ploneout/trunk plone3 $ cd plone3 $ python boostrap.py # only needed once $ bin/buildout # needed each time you change buildout.cfg $ bin/instance fg # start zope What's nice is that we can point new developers at this and they have a fully replicable environment for proper development on Plone 3 itself. The plone eggs are in src/ and products in products/, via svn:externals, so you can work on them and then commit changes. If you were using this for your own project and you wanted to Plone, CMF and all the eggs only as a dependency, maybe with your own eggs and products in development mode, you can create a buildout.cfg by answering a couple of questions (or accepting the defaults) from paster. $ easy_install ZopeSkel # gets Zope/Plone templates for paster $ paster create -t plone3_buildout myproject $ cd myproject $ python bootstrap.py $ bin/buildout The buildout.cfg file contains a list of the eggs you want, and you tend to put development eggs for your project in src/ and reference them in buildout.cfg. Daniel Nouri has a slightly different approach, using workingenv.py. Whereas buildout.cfg is a single-file configuration for the eggs, downloads and other build steps you want in your environment, his ploneenv approach creates a more traditional Zope instance. It's more for projects using Plone as dependency again, because it basically installs the Plone egg, which in turn keeps track of all the various eggs we have as dependencies and all the products. There could be a CMF meta-egg that'd work similarly. $ easy_install ploneenv $ ploneenv -m /path/to/zope/utilities/mkzopeinstance.py myproject $ bin/zopectl fg # as usual The workingenv approach lets you install eggs into it, not interfering with global site-packages, using the local bin/easy_install. If you prefer, you can source bin/activate and it'll set your PATH and PYTHONPATH as necessary so that your shell is always in the local environment. decativate (or quitting your shell) turns that off again. Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Charlie Clark wrote: Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Ever heard of sys.path? Sure, I mean, that's all they do, manage sys.path for you. But it's way easier to be more declarative about your dependencies and their versions, and having automatic downloads of dependencies (even indirect ones) can save a lot of time and make it easier to try things out. Sorry, I don't want to waste bandwidth on the CMF list on a flame war. Eggs are there and I will have to learn to live with them but I don't have to like them. I'm not quite sure it's wasted bandwidth in the sense that I believe moving to distribution using eggs could benefit CMF and its dependents greatly. This pressure is coming from both sides: Zope (3) and Plone. I'm pretty sure the Silva guys are fairly enthusiastic about eggs, too. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Meanwhile, the rest of the Python world came up with something better and more widely accepted. Until Zope 2.10 and Plone 3, the whole Plone and CMF stack depended on no library that was re-usable outside of Zope (apart from PIL, and unless you count parts of Zope 3 shipped with Zope 2.8+). Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Works fine for mxODBC Managing lib/python manually is quite painful. For example, we have a lot of things we want to keep in the plone.* namespace. These are developed by different people. When people had to symlink things in (before we got eggs) or we were building bundles, merging multiple packagings of libraries into lib/python/plone/ and lib/python/plone/app became difficult, time-consuming and really, really hard to explain to newbies. Mostly, I'm basing this on empirical evidence, though. In the latter part of the Plone 3 development cycle, we started pushing eggs pretty hard. We got familiar with tools like paster, setuptools and easy_install which help make this fairly painless. Before Plone 3, we made no use of external, non-Zope specific libraries (apart from PIL); to be honest, we hardly even looked for them, because of the distribution headache (Plone at that point was a tarball for Products/). Now, we've got half a dozen or so packages that other people (primarily Zope 3 people for now, but as Zope 3 becomes eggified as well it gets easier to re-use things outside Zope entirely) can use (grok is playing with our AJAX infrastructure, for example). We also know that we can find, try and ultimately declare dependencies for packages quite easily. I don't think eggs/setuptools are perfect. But I don't think they're useless either, and on the whole, so far, they've brought more benefits than problems. By playing with eggs, we're playing better with the rest of the Python community (and things like entry points are very cool). We start being able to re-use some of their tools (workingenv, buildout, paster) and participate more meaningfully by sharing code. In any case, I don't mean this to be acrimonious in any way. I'm justing saying that depending on a non-Products package (be it egg-distributed or not) shouldn't be a problem (because there will only be more and more of these). Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Charlie Clark wrote: Am 06.02.2007 um 22:14 schrieb Rocky: Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of regular python code but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I can see why people would be appalled by easy_install, at least in its default incarnation (inside a workingenv or a zc.buildout it's quite nice). There's little to be afraid for concerning eggs, though. They're just directories with Python packages in them (they often come in a ZIP form and may also be installed that way, which doesn't chagne the fact that they're just directories with Python packages in them). I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. I have no idea what local Products should be, but the Products package contains more magic than anybody should have to handle. The whole reason we have zopectl debug and zopectl test instead of a simple debugzope and test script (like we do have in Zope 3) is that Zope wants an extra special treatment for its Products thing. Doese zopectl work on Windows? No, it doesn't, because it builds on zdaemon. There, Products sucks. If Products were usinig standard Python idioms like namespace packages, etc., we wouldn't have that problem. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. Who says you have to. It seems to me that the only people here complaining are the ones who aren't quite familiar with eggs yet. Also, I seem to detect a general tone of skepticism against the new tools that the greater Python community is building. I can only encourage people to take a look at thigns like workingenv and zc.buildout and at what the Zope and Plone communities have done with these tools. Perhaps they don't allow you to use simple symlinks for deployment, but perhaps they offer something similiar, something even easier and a few additional extra features perhaps? It's worth at least checking these things out. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. Eggs contain Python packages. How you deploy the Python packages is your choice. If you like copying or symlinking, fine. And, heck, you can still symlink your products to Products. Nobody's getting rid of Products. But please-oh-please let us start developing new things in regular packages so that we can a) make use of the tools provided to us by the greater Python community b) ease other Python programmers into Zope (no more weird Products, no more Zope stinks, no more Zope is its own universe). Some of us *like* reaching out. c) make things easier for *ourselves* (being able to test a simple Python package outside the context of a full-blown Zope instance is a tremendous win). -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Martin Aspeli wrote: I don't think eggs/setuptools are perfect. But I don't think they're useless either, and on the whole, so far, they've brought more benefits than problems. By playing with eggs, we're playing better with the rest of the Python community (and things like entry points are very cool). We start being able to re-use some of their tools (workingenv, buildout, paster) and participate more meaningfully by sharing code. In any case, I don't mean this to be acrimonious in any way. I'm justing saying that depending on a non-Products package (be it egg-distributed or not) shouldn't be a problem (because there will only be more and more of these). Good points. To summarize: * eggs aren't the holy grail, but they bring many benefits. * at this point, we shouldn't create artificials hurdles that prevent us from putting new things into packages and hence taking advantages of eggs. Nobody's tearing down old walls, but at least let's not stop building new ones. That's all I can and will say in this matter. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Rocky wrote: On Feb 5, 5:40 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 5 Feb 2007, at 19:43, Rocky Burt wrote: On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). Not knowing any better I was assuming there'd be a Zope 2-style product, which we could pull in as a SVN external? Hm... well, as long as I avoid absolute imports in five.localsitemanager there's no reason it couldn't be included into a CMF product (perhas CMFCore ?) via svn:externals. Please don't. Relative imports are evil. It's seriously a big wart in Python 2 and will thankfully be fixed in Python 3. Until then I can only recommend absolute imports everywhere. Yes, they're more to type, but at least I've been bitten too often. That's not something I'm particularly fond of but I'm not against it. But as time moves on this is going to become more and more of an issue for CMF (code that isn't expected to live in Products/). Right. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
On 2/7/07, Charlie Clark [EMAIL PROTECTED] wrote: Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Yup, we sure mean that. Ever heard of sys.path? Yeah, which is what eggs use an manage for you. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? They shouldn't. The point is that we want third-party libraries to be available as Zope add-ons in much the same way as Zope Products are. But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Sure, but one of the things, the easy of use you talk about, is that if everything is products you can make an svn-bundle, and just check it out into the products directory. You can't do that if you need it to be in several places. I currently solve this with my own libraries by making Zope products for the libraries as well, that put the libraries into sys.path if they don't already exist there. But that's only possible with libraries that I have control over. Bildout, ploneout and workingenv are there to try to solve these problems. If you don't like *them* I fully understand. They annoy me since they install like, every again, which takes time, and their complicated, and developer packages that ue them often require me to create a new Zope-instance even if I don't want to. But eggs? Eggs are great. Instead of separately downloading, compiling and installing five packages, all you do is easy_install blah and it does it for you. I really don't see how anybody can gripe about that. And if you don't want to use it, then don't. Then download, compile and install each paclage separately of you have to. Nobody is FORCING you to use eggs. -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens! Jens Vagelpohl wrote: On 2 Feb 2007, at 20:32, yuppie wrote: I'm going to spend some time this weekend adding unregisterUtility where needed. Thanks for your help! That's no longer necessary. I changed the set up / tear down for non-functional layers. The layers now call cleanUp() after each test. Maybe there are still some non-layer tests that should have a cleanUp(), but at least with the order tests are run in my sandbox all cleanup issues are resolved. OK, sounds good, I misunderstood your email. No. You understood my email correctly, but it is out-dated. I made some more changes after writing it. I suppose the last bit left to do now is the custom site manager. Rocky? :) The site manager is the most important part. Two other issues come to my mind: - Does migration of existing sites already work? - At least in theory SkinnableObjectManager and SkinsContainer were generic base classes that could be used for other purposes as well. Now they are tied to the site object and the skins tool. Don't know if anybody used them for something else and needs BBB code. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens! Jens Vagelpohl wrote: On 22 Jan 2007, at 01:43, Philipp von Weitershausen wrote: Jens Vagelpohl wrote: Other than that I have one unrelated failure in the GS tests themselves and some logger messages coming through, all those smell like test cleanup issues to me. If I run the GenericSetup tests by themselves I don't get any failure. Shrug. Long live layers to push all the Zope 2 crap into that can't be torn down. The logging message happens in a layer, Products.CMFCalendar.testing.FunctionalLayer. I have to admit that anything having to do with either the CMFCalendar FunctionalLayer or the CMFCore FunctionalLayer has been a pain in the ass to fix with this utility work. The logging messages no longer show up and I simplified the FunctionalLayer tests. No need to register the tools again - setSite(self.app.site) sets up the correct registry. But the cleanup issues are still not resolved. AFAICS the problem is caused by the new registerUtility() calls that pollute the global registry. Inside layers we can't use cleanUp() because it would destroy the layer setup. I'm afraid each test needs an explicit unregisterUtility() for each registered tool. Or maybe we should perform a complete set up / tear down for each unit test, not just for the layer. This way we can always use cleanUp(). That might not be too expensive for non-functional tests. Functional tests don't have the same problem because there is no need to mess around with the global registry. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote:
I have now finished (well, finished awaiting feedback and help on one
item) the work on the jens_tools_as_utilities branch.
There's one set of test failures out of
CMFActionIcons/tests/test_exportimport that I can't quite interpret. I
believe it has to do with the way the tests are set up, but I'm not
sure. See traceback below.
You want to register the DefaultTraversable adapter for * (None). I'm
sure other tests in the CMF do this already, it should be easy to adapt
their setup code to that test.
Other than that I have one unrelated failure in the GS tests themselves
and some logger messages coming through, all those smell like test
cleanup issues to me. If I run the GenericSetup tests by themselves I
don't get any failure.
Shrug.
Long live layers to push all the Zope 2 crap into that can't be torn down.
Error in test test_with_icon
(Products.CMFActionIcons.tests.test_exportimport.Test_exportActionIconsTool)
Traceback (most recent call last):
[snip]
File
/usr/local/zope/src/Zope-2.10-branch/lib/python/zope/traversing/adapters.py,
line 161, in traversePathElement
raise TraversalError('No traversable adapter found', obj)
TraversalError: ('No traversable adapter found',
Products.CMFActionIcons.exportimport.ActionIconsToolExportConfigurator
object at 0x3782510)
--
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens, all!
I haven't seen any progress on the tools as local utilities story for
some time now. Is there anything specific I can help with?
Jens Vagelpohl wrote:
On 22 Nov 2006, at 12:15, Hanno Schlichting wrote:
At the time I wrote this it was kind of experimental and I didn't know
if I could make it work. So I put it in an add-on with the clear
intention to merge it back into GenericSetup once it was reasonably
stable and working. Thx for taking over that part :)
Thanks for the code ;)
I have taken another look at the code and fixed some obvious bugs. As I
still have no commit rights for the svn repo (yes, entirely my fault)
could somebody commit the attached patch (against GS trunk) for me?
With this patch applied I think at least the utility handlers are fully
functional. As I haven't written tests for the adapter handlers so far,
I'm not sure for those yet ;)
Thx in advance,
Hanno
Index: tests/test_components.py
===
--- tests/test_components.py(revision 71534)
+++ tests/test_components.py(working copy)
@@ -24,10 +24,14 @@
from Products.Five.component import enableSite
from Products.Five.component.interfaces import IObjectManagerSite
+from Products.GenericSetup.interfaces import IBody
from Products.GenericSetup.testing import BodyAdapterTestCase
from Products.GenericSetup.testing import ExportImportZCMLLayer
+from Products.GenericSetup.tests.common import DummyExportContext
+from Products.GenericSetup.tests.common import DummyImportContext
from zope.app.component.hooks import setSite, clearSite, setHooks
+from zope.component import getMultiAdapter
from zope.component import getSiteManager
from zope.component import queryUtility
from zope.component.globalregistry import base
@@ -50,12 +54,6 @@
def verify():
Returns True.
-class IDummyInterface2(Interface):
-A second dummy interface.
-
-def verify():
-Returns True.
-
class DummyUtility(object):
A dummy utility.
@@ -64,28 +62,31 @@
def verify(self):
return True
-class DummyUtility2(object):
-A second dummy utility.
+class DummyTool(SimpleItem):
+A dummy tool.
+implements(IDummyInterface)
-implements(IDummyInterface2)
+id = 'dummy_tool'
+meta_type = 'dummy tool'
+security = ClassSecurityInfo()
+security.declarePublic('verify')
def verify(self):
return True
-dummy2 = DummyUtility2()
-
-class DummyTool(SimpleItem):
-A dummy tool.
+class DummyTool2(SimpleItem):
+A second dummy tool.
implements(IDummyInterface)
-id = 'dummy_tool'
-meta_type = 'dummy tool'
+id = 'dummy_tool2'
+meta_type = 'dummy tool2'
security = ClassSecurityInfo()
security.declarePublic('verify')
def verify(self):
return True
+
InitializeClass(DummyTool)
_COMPONENTS_BODY = \
@@ -100,12 +101,10 @@
object=/dummy_tool/
utility name=dummy tool name2
interface=Products.GenericSetup.tests.test_components.IDummyInterface
- object=/test_folder_1_/dummy_tool/
+ object=/test_folder_1_/dummy_tool2/
utility name=foo
factory=Products.GenericSetup.tests.test_components.DummyUtility
interface=Products.GenericSetup.tests.test_components.IDummyInterface/
- utility component=Products.GenericSetup.tests.test_components.dummy2
- interface=Products.GenericSetup.tests.test_components.IDummyInterface2/
/utilities
/componentregistry
@@ -115,6 +114,32 @@
layer = ExportImportZCMLLayer
+def test_body_get(self):
+self._populate(self._obj)
+context = DummyExportContext(self.app)
+adapted = getMultiAdapter((self._obj, context), IBody)
+self.assertEqual(adapted.body, self._BODY)
+
+def test_body_set(self):
+context = DummyImportContext(self.app)
+adapted = getMultiAdapter((self._obj, context), IBody)
+adapted.body = self._BODY
+self._verifyImport(self._obj)
+self.assertEqual(adapted.body, self._BODY)
+
+# now in update mode
+context._should_purge = False
+adapted = getMultiAdapter((self._obj, context), IBody)
+adapted.body = self._BODY
+self._verifyImport(self._obj)
+self.assertEqual(adapted.body, self._BODY)
+
+# and again in update mode
+adapted = getMultiAdapter((self._obj, context), IBody)
+adapted.body = self._BODY
+self._verifyImport(self._obj)
+self.assertEqual(adapted.body, self._BODY)
+
def _getTargetClass(self):
from Products.GenericSetup.components import \
ComponentRegistryXMLAdapter
@@ -139,19 +164,15 @@
self.assertEqual(tool.meta_type, 'dummy tool')
self.assertEquals(repr(util), repr(tool))
-util = queryUtility(IDummyInterface2)
-self.failUnless(IDummyInterface2.providedBy(util))
-self.failUnless(util.verify())
-
util =
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12 Dec 2006, at 00:14, Hanno Schlichting wrote: I haven't seen any progress on the tools as local utilities story for some time now. Is there anything specific I can help with? Sorry, I have a bunch of changes sitting on my computer right now (making portal_catalog a utility), but customer work and a lot of failing unit tests have prevented me from doing much. I'm hoping to get back to it ASAP, depending on progress on the main project I am involved in now. I have taken another look at the code and fixed some obvious bugs. As I still have no commit rights for the svn repo (yes, entirely my fault) could somebody commit the attached patch (against GS trunk) for me? With this patch applied I think at least the utility handlers are fully functional. As I haven't written tests for the adapter handlers so far, I'm not sure for those yet ;) I'll look at that patch right now. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFfellRAx5nvEhZLIRAlvsAJ4zFNasFqJSwhFhV1FCzOra10ahywCfbVBS zpw/ezSfCLcVVItsui18440= =4rEh -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens! Jens Vagelpohl wrote: - - There are failing tests in CMFCore.exportimport.tests.test_actions, basically everything that derives from CMFCore.exportimport.tests.test_actions._ActionSetup. The insidious thing is this: - running all tests or all CMFCore tests shows the failures - running *just* the CMFCore.exportimport tests _passes_ Right now I don't know if the main problem is about the test harness setup in _ActionSetup, or if there is some strange test interaction/test cleanup issue. Actually both. The test setup depends on some 'magic' that only works if the test is part of the *first* layer run by the testrunner. That's the case if you run only the CMFCore.exportimport tests, but not if you run all CMFCore tests. The tests require the site hooks set up correctly, which should be done explicitly in the test setup. This is what happens if you don't do it explicitly: 1.) the layer's setUp() loads Products.Five's meta.zcml - this loads the Products.Five.site's meta.zcml - this triggers an import of Products.Five.site.fiveconfigure - this makes an (unused) import from Products.Five.site.localsite - this imports Products.Five.component (for the BBB code) - Products.Five.component sets the site hooks 2.) the layer's tearDown() resets the hooks 3.) the next layer can't set up the hooks the same way This is really nasty, Five should have a more explicit way to set the site hooks. Tracking this down did cost me several hours :( I just checked in a fix for the ExportImportZCMLLayer. If local utilities are used in other layers as well, they need the same fix. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens, all. Why did you pick exactly the two weeks where I'm on vacation without an Internet connection to do this? Anyways by reading through the mailing list it seems you have figured it all out by now ;) Jens Vagelpohl wrote: I have to run off right now, but a quick look over GSLocalAddons suggests it should be part of the main CMF Default GS profile, and doing it with GenericSetup certainly is the way to go. Why did Hanno not put it into the CMF base profile right from the start, dangit! At the time I wrote this it was kind of experimental and I didn't know if I could make it work. So I put it in an add-on with the clear intention to merge it back into GenericSetup once it was reasonably stable and working. Thx for taking over that part :) The dumb but simple reason why I didn't start folding this back in myself is that (besides the usual lack of time) I don't have commit rights on svn.zope.org. As I'm quite lazy could anybody point me to the current process of getting those or tell me what I have to do? Thx, Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22 Nov 2006, at 12:15, Hanno Schlichting wrote: Why did you pick exactly the two weeks where I'm on vacation without an Internet connection to do this? Very careful planning. At the time I wrote this it was kind of experimental and I didn't know if I could make it work. So I put it in an add-on with the clear intention to merge it back into GenericSetup once it was reasonably stable and working. Thx for taking over that part :) Thanks for the code ;) As I'm quite lazy could anybody point me to the current process of getting those or tell me what I have to do? You need to go through Jim who will provide you with a contributor agreement to sign. He will open up access once that's done. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFZDUORAx5nvEhZLIRAt26AJ9QNwtL7vt0Os23lTrG3hqFCVPvkACgurJn aLThl2FuqPl6O5A7veJOk2w= =C96N -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens! Jens Vagelpohl wrote: Using just the ActionsTool right now in order to get that all set up and then move to the other tools, I've gotten almost always there, but there is one set of tests that refuse to run right now, the ones in CMFCore.exportimport.tests.test_actions which derive from class _ActionSetup. Here's the change I have made in the actions importer code so far: [...] I've spent several hours and can't make those tests work. Anyone have a hint for me? Looking at the diffs doesn't give me any clue, but obviously *something* is set up wrong. Two remarks: - The test fixture for the exportimport tests is quite old-fashioned. I was not able to change them together with the other tests because they depend on base classes in GenericSetup. Since the GenericSetup trunk is now opened for new development, these tests should be modernized as well. It might be easier to do that first instead of trying to fix the old test setup. - It might be easier to help you if you would check in your CMF changes on a branch. I did not want to step on your toes, so I planned to modernize the exportimport tests *after* you are done with your local utilities changes. But I can make this high priority if it should be done *before* you finish your changes. I propose 1.) I refactor the exportimport tests in GenericSetup trunk and CMF trunk using layers. 2.) You merge those changes into your CMF sandbox and check it in on a branch. 3.) We work together on the remaining issues on that branch. 4.) When the issues are resolved, you merge the changes into the trunk. Does that make sense? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19 Nov 2006, at 16:47, yuppie wrote: I did not want to step on your toes, so I planned to modernize the exportimport tests *after* you are done with your local utilities changes. But I can make this high priority if it should be done *before* you finish your changes. I propose 1.) I refactor the exportimport tests in GenericSetup trunk and CMF trunk using layers. 2.) You merge those changes into your CMF sandbox and check it in on a branch. 3.) We work together on the remaining issues on that branch. 4.) When the issues are resolved, you merge the changes into the trunk. That sounds like a great plan, I really appreciate the help! For right now, I will continue by converting the getToolByName calls for other tools, and will ignore those specific exportimport tests until you're done. Since there were no such problems with other layer- based tests it is possible your changes could solve the issue already. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFYH9mRAx5nvEhZLIRAvU+AKCuaOPTVo5u7Th30DglFph13REPmgCcCDif uG3o+oftiYqBIjLmZNSycQg= =MN4/ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Sun, 2006-19-11 at 14:37 +0100, Jens Vagelpohl wrote: Using just the ActionsTool right now in order to get that all set up and then move to the other tools, I've gotten almost always there, but there is one set of tests that refuse to run right now, the ones in CMFCore.exportimport.tests.test_actions which derive from class _ActionSetup. Here's the change I have made in the actions importer code so far: snipping some code... Export actions tool. site = context.getSite() - -tool = getToolByName(site, 'portal_actions', None) +tool = getUtility(IActionsTool, context=site) This looks like it will be the new way of looking up CMF tools? Looks great. But we shouldn't have to specify ``context=site`` should we? getUtility should automatically figure out what the nearest chain of sites should be and look for local utilities in each one of them automatically no? - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: On Sun, 2006-19-11 at 14:37 +0100, Jens Vagelpohl wrote: Using just the ActionsTool right now in order to get that all set up and then move to the other tools, I've gotten almost always there, but there is one set of tests that refuse to run right now, the ones in CMFCore.exportimport.tests.test_actions which derive from class _ActionSetup. Here's the change I have made in the actions importer code so far: snipping some code... Export actions tool. site = context.getSite() - -tool = getToolByName(site, 'portal_actions', None) +tool = getUtility(IActionsTool, context=site) This looks like it will be the new way of looking up CMF tools? Looks great. For the sake of backward compatibility, I'm thinking we should re-implement 'getToolByName' to use a map of tool name to interface, and call 'queryUtility' using that interface; it can then fall back to an acquired getattr and issue a deprecation warning if that fails (maybe warn either way?) But we shouldn't have to specify ``context=site`` should we? getUtility should automatically figure out what the nearest chain of sites should be and look for local utilities in each one of them automatically no? That won't work unless the tests set up the thread-local site in the same way that the publisher does. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFYJuW+gerLs4ltQ4RAmDqAKCFt9ggbQenaF7/cVV82TGvLi7qPwCgwXml 9LBVwYnpq9znZw++xwPyhd0= =yTg1 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Sun, 2006-19-11 at 12:59 -0500, Tres Seaver wrote: Rocky Burt wrote: But we shouldn't have to specify ``context=site`` should we? getUtility should automatically figure out what the nearest chain of sites should be and look for local utilities in each one of them automatically no? That won't work unless the tests set up the thread-local site in the same way that the publisher does. Right, but the code mentioned earlier was in code that is expected to run in testing and non-testing environments alike. So it definitely shouldn't use the context parameter and the tests should accommodate accordingly (by setting up the thread-local site or whatever). - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19 Nov 2006, at 18:59, Tres Seaver wrote: Export actions tool. site = context.getSite() - -tool = getToolByName(site, 'portal_actions', None) +tool = getUtility(IActionsTool, context=site) This looks like it will be the new way of looking up CMF tools? Looks great. For the sake of backward compatibility, I'm thinking we should re-implement 'getToolByName' to use a map of tool name to interface, and call 'queryUtility' using that interface; it can then fall back to an acquired getattr and issue a deprecation warning if that fails (maybe warn either way?) Yes, this map is part of the change, including deprecation warning and all. By the way, getToolByName was exposed to untrusted code used in places like skin scripts as well - I suppose for those we need to provide some alternative that is callable from untrusted code. But we shouldn't have to specify ``context=site`` should we? getUtility should automatically figure out what the nearest chain of sites should be and look for local utilities in each one of them automatically no? That won't work unless the tests set up the thread-local site in the same way that the publisher does. Right - and that's most likely where I am doing something wrong. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFYMGjRAx5nvEhZLIRAuF0AJ4ymVgjQCMw6FlIPSH+iMsxGM1iXACgsCLm EO3PTIMMIAhRct8OadDt6Dg= =Eu9u -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens! Jens Vagelpohl wrote: So I'm currently stealing^H^H^H^H^H^H^H integrating Hanno's code from GSLocalAddons into CMFCore and CMFDefault. AFAICS GSLocalAddons doesn't depend on CMF and might be useful for other projects as well. Don't know if you did that already, but please add the code to GenericSetup, not CMFCore. I think this is a good time to create a maintenance branch for GenericSetup 1.2 and to make the GenericSetup trunk depend on Zope 2.10. I'm running into an issue with the site/site manager registration, though. It does not work when instantiating the site, but it does when going to the setup tool in the newly created site afterwards and telling it to import all steps. Analogous to the way it is done in Plone I have parked the site/site manager stuff in CMFDefault.setuphandlers.importVarious for now, [...] Since CMF site roots have anyway their own class, I think we should hardcode the Zope 3 site stuff. I only had a quick look at the code so I might be missing something, but implementing this in PortalObjectBase seems to be quite easy. And we would neither need to use importVarious nor to write migration code. Just my 2 cents, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14 Nov 2006, at 11:41, yuppie wrote: Hi Jens! Jens Vagelpohl wrote: So I'm currently stealing^H^H^H^H^H^H^H integrating Hanno's code from GSLocalAddons into CMFCore and CMFDefault. AFAICS GSLocalAddons doesn't depend on CMF and might be useful for other projects as well. Don't know if you did that already, but please add the code to GenericSetup, not CMFCore. I think this is a good time to create a maintenance branch for GenericSetup 1.2 and to make the GenericSetup trunk depend on Zope 2.10. Good point, right now the code is purely in the CMF, but it can be moved. I'll create the 1.2 branch right now and then move the GSLocalAddons bits into GenericSetup trunk, and change DEPENDENCIES.txt. I'm running into an issue with the site/site manager registration, though. It does not work when instantiating the site, but it does when going to the setup tool in the newly created site afterwards and telling it to import all steps. Analogous to the way it is done in Plone I have parked the site/ site manager stuff in CMFDefault.setuphandlers.importVarious for now, [...] Since CMF site roots have anyway their own class, I think we should hardcode the Zope 3 site stuff. I only had a quick look at the code so I might be missing something, but implementing this in PortalObjectBase seems to be quite easy. And we would neither need to use importVarious nor to write migration code. Looking at the calls that are being done to make it into a Zope 3 site it seems a complicated affair to hardcode that stuff in at class level so that it will be picked up for older installations. Do you have any specific ideas about that? Otherwise it is easy to at least move the code from importVarious into a handler for ISiteRoot/ IObjectAddedEvent. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFWc9QRAx5nvEhZLIRApFcAJ9PRBhb9+d+5G4GhD6zwWi+QvHMLgCfUVQW YdCyEnxK7sko826Lase4jOg= =zKeg -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10 Sep 2006, at 16:08, Tres Seaver wrote:
Rocky Burt wrote:
On Sat, 2006-09-09 at 21:57 +0100, Martin Aspeli wrote:
Hi guys,
philiKON pointed out something interesting to me the other day - we
could actually register the existing tools as local utilities as
of Zope
2.10. That way, you could do this:
actions = getUtility(IActionsTool)
as another spelling for
actions = getToolByName(context, 'portal_actions')
But now we're being more consistent with Zope 3, we are using a
proper
interface and not just a string to check, we don't have to worry
about
passing a context parameter (though tests have to do a setSite()
call),
and we can let the registration be overridden with the component
registry operations.
+10 on this idea from me.
+1 here, too. In fact, being able to make this switch is the *reason*
'getToolByName' was introduced in the first placey.
I am experimenting with that right now, but my z3/Five-Fu ran low
again ;) My problem: calls to zope.component.getUtility
(interface_class) never return anything. Here's the top part (the
bottom is just the old way) of my CMFCore.utils.getToolByName:
def getToolByName(obj, name, default=_marker):
Get the tool, 'toolname', by acquiring it.
tool_iface = _tool_iface_registry.get(name)
if tool_iface is not None:
warn('getToolByName is deprecated, please use getUtility(%
s)' % (
tool_iface.__name__), DeprecationWarning, stacklevel=2)
try:
tool = getUtility(tool_iface, context=obj)
return tool
except ComponentLookupError:
# behave in backwards-compatible way
if default is _marker:
raise AttributeError, name
I have a simple registration going and have one ID - interface
registered (in _tool_iface_registry), 'portal_actions' is mapped to
interface class CMFCore.interfaces._tools.IActionsTool. No matter how
I try to call getUtility, I always get a ComponentLookupError.
I am probably missing some kind of component registration - I have
not made any ZCML changes or changes to the code in
CMFCore.ActionsTool, except for one line that causes the tool to be
registered in the internal _tool_iface_registry.
Help! :)
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFFWIV+RAx5nvEhZLIRAkpoAJ9TH7acz2//aWnjI3e+dGoTLnnHcwCfXAuH
t9KiABUMVqTdmlU6S5/knjo=
=2Qje
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
I am experimenting with that right now, but my z3/Five-Fu ran low
again ;) My problem: calls to zope.component.getUtility
(interface_class) never return anything. Here's the top part (the
bottom is just the old way) of my CMFCore.utils.getToolByName:
Yay!
def getToolByName(obj, name, default=_marker):
Get the tool, 'toolname', by acquiring it.
tool_iface = _tool_iface_registry.get(name)
if tool_iface is not None:
warn('getToolByName is deprecated, please use getUtility(%
s)' % (
tool_iface.__name__), DeprecationWarning,
stacklevel=2)
try:
tool = getUtility(tool_iface, context=obj)
return tool
except ComponentLookupError:
# behave in backwards-compatible way
if default is _marker:
raise AttributeError, name
The 'context' argument *should* be superfluous, because Zope's thread-local
should know what the local site is, and a utility is registered with exactly
one local site.
I have a simple registration going and have one ID - interface
registered (in _tool_iface_registry), 'portal_actions' is mapped to
interface class CMFCore.interfaces._tools.IActionsTool. No matter how
I try to call getUtility, I always get a ComponentLookupError.
I am probably missing some kind of component registration - I have
not made any ZCML changes or changes to the code in
CMFCore.ActionsTool, except for one line that causes the tool to be
registered in the internal _tool_iface_registry.
You'll need to actually register the utility with the local component
registry. I assume we're on Zope 2.10 here? This needs to happen wehn the
CMF site is set up.
Take a look at
http://svn.plone.org/svn/plone/CMFPlone/trunk/setuphandlers.py.
In particular:
def enableSite(self, portal):
Make the portal a Zope3 site and create a site manager.
enableSite(portal, iface=IObjectManagerSite)
components = PersistentComponents()
components.__bases__ = (base,)
portal.setSiteManager(components)
After this is done, you can do:
from zope.component import getSiteManager
site = CMF site
actionsTool = site.portal_actions # get the actual object from the ZODB
sm = getSiteManager(site)
sm.registerUtility(provides=IActionTool, component=actionsTool)
Now, you can do this with GenericSetup as well, thanks to Hanno. See
http://svn.plone.org/svn/collective/GSLocalAddons/trunk/
The test is informative:
http://svn.plone.org/svn/collective/GSLocalAddons/trunk/tests/test_components.py
Hanno said he was interested in factoring GSLocalAddOns into CMF itself, so
maybe now's a good time to do so.
Martin
--
View this message in context:
http://www.nabble.com/Tools-as-local-utilities-tf2245411.html#a7318607
Sent from the Zope - CMF list2 mailing list archive at Nabble.com.
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Now, you can do this with GenericSetup as well, thanks to Hanno. See http://svn.plone.org/svn/collective/GSLocalAddons/trunk/ The test is informative: http://svn.plone.org/svn/collective/GSLocalAddons/trunk/tests/ test_components.py Hanno said he was interested in factoring GSLocalAddOns into CMF itself, so maybe now's a good time to do so. Alright, that's what I thought, I need to wave a lot more dead domestic fowl ;) I have to run off right now, but a quick look over GSLocalAddons suggests it should be part of the main CMF Default GS profile, and doing it with GenericSetup certainly is the way to go. Why did Hanno not put it into the CMF base profile right from the start, dangit! Now, seeing how this magic is done upon instantiation, I assume it means existing sites are screwed or need a separate upgrade script? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFWI2nRAx5nvEhZLIRAhMTAJ0Yb4bzMURjzXPmiha7pmr3wJEuOACgny2x Eqz5/u1mrHoMJ7alh9Dw0vk= =dj3w -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 13 Nov 2006, at 16:22, Jens Vagelpohl wrote: I have to run off right now, but a quick look over GSLocalAddons suggests it should be part of the main CMF Default GS profile, and doing it with GenericSetup certainly is the way to go. Why did Hanno not put it into the CMF base profile right from the start, dangit! So I'm currently stealing^H^H^H^H^H^H^H integrating Hanno's code from GSLocalAddons into CMFCore and CMFDefault. I'm running into an issue with the site/site manager registration, though. It does not work when instantiating the site, but it does when going to the setup tool in the newly created site afterwards and telling it to import all steps. Analogous to the way it is done in Plone I have parked the site/site manager stuff in CMFDefault.setuphandlers.importVarious for now, which now contains code like this: --- snip from Products.Five.component import enableSite from Products.Five.component.interfaces import IObjectManagerSite from zope.component.globalregistry import base from zope.component.persistentregistry import PersistentComponents /snip snip def importVarious(context): Import various settings. site = context.getSite() # Make the portal a Zope3 site and create a site manager. enableSite(site, iface=IObjectManagerSite) components = PersistentComponents() components.__bases__ = (base,) site.setSiteManager(components) /snip -- My new handler for the component registry is all set up and registered correctly, and the various import step that calls importVarious is set as a dependency for the component registry import step. The dependency works, it is indeed run right before my new step. However, registration fails, because a call to zope.app.component.hooks.getSite in my component registry setup handler returns None, as if the registration in importVarious had not been done. When re-running all steps manually from the setup tool afterwards it magically works and the component registry is populated... Perhaps the thread-local site hook needs to be set first, before trying to use the site manager? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWOUc+gerLs4ltQ4RAlBLAKCcQM79BBflqlw332vwQcW4I5Pc8gCcDsXB SaBgDJmEojH4z7pljPBGR5Y= =ogeW -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13 Nov 2006, at 22:35, Tres Seaver wrote: My new handler for the component registry is all set up and registered correctly, and the various import step that calls importVarious is set as a dependency for the component registry import step. The dependency works, it is indeed run right before my new step. However, registration fails, because a call to zope.app.component.hooks.getSite in my component registry setup handler returns None, as if the registration in importVarious had not been done. When re-running all steps manually from the setup tool afterwards it magically works and the component registry is populated... Perhaps the thread-local site hook needs to be set first, before trying to use the site manager? That would make entirely too much sense. Damn, foiled again ;) Adding a call to zope.app.component.hooks.setSite and passing in the CMF site after the other magic in importVarious solved the problem. Thanks! jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFWO+WRAx5nvEhZLIRAgZUAJwJoogy1qmfAhD1pzXYk7J2lHCfkwCePTnO WWaxgCL+/CHHcKs1BAfYsJg= =Vw1F -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13 Sep 2006, at 13:06, Miles Waller wrote: Personally, I'm neutral on moving the requirement for CMF 2.1 to Zope 2.10. Obviously we're not using any of those new features yet, but it would be nice to enable their use by mandating 2.10. CMF 2.2 will move the bar higher I'd wager. I'd love to hear some kind of yay/nay for making Zope 2.10 the required platform for CMF 2.1 from some other people like Tres, Yvo, Florent etc. One thing that would be good about this is that the CMFUid suite could be deprecated in favour of an implementation based on zope3's intids utility. There was a discussion a while back about the future of that package: http://mail.zope.org/pipermail/zope-cmf/2006-April/ 024373.html Yes, that would be a good thing, CMFUid isn't as alive as it was hoped when the product was pushed into the CMF. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFCQEbRAx5nvEhZLIRAugsAJ4pBxmqKlHdlMjiaiJSCVGLRsTIcQCfc7X2 DrrAhYmOiDB8CTbxITFDOhM= =Nuwz -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10 Sep 2006, at 20:09, Martin Aspeli wrote: Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? 2.10 really is lovely, because Zope 3.3 is lovely. :) The local components story is much, much better. Look at Hanno's GSLocalAddOns package (which really should move to CMFCore once CMFCore is happy to require 2.10+), or other examples. Basically, it solves a lot of the problems we had with 2.9 and earlier in that it was hard to make things installable into a CMF site - a global utility or adapter was an either-or proposition for all sites in a Zope instance. Being able to use local adapters (and local event handlers) is also very useful. Plus, the whole story around formlib, zope.contentprovider, zope.viewlet is improved, (these three tools are great - if you haven't played with them, go read the doctests, or Rocky's formlib tutorial on plone.org) and Five has caught up to these to make them accessible to us. Personally, I'm neutral on moving the requirement for CMF 2.1 to Zope 2.10. Obviously we're not using any of those new features yet, but it would be nice to enable their use by mandating 2.10. CMF 2.2 will move the bar higher I'd wager. I'd love to hear some kind of yay/nay for making Zope 2.10 the required platform for CMF 2.1 from some other people like Tres, Yvo, Florent etc. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFB7HdRAx5nvEhZLIRAqh0AJoDrhahQK1Q+vCqpxS0j8YICDLCoQCbBdlO D5pbM5yW6tAzr5bmqNt7mco= =aXQo -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Sun, 2006-10-09 at 12:57 +0200, Jens Vagelpohl wrote: On 9 Sep 2006, at 22:57, Martin Aspeli wrote: philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Sat, 2006-09-09 at 21:57 +0100, Martin Aspeli wrote: Hi guys, philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: actions = getUtility(IActionsTool) as another spelling for actions = getToolByName(context, 'portal_actions') But now we're being more consistent with Zope 3, we are using a proper interface and not just a string to check, we don't have to worry about passing a context parameter (though tests have to do a setSite() call), and we can let the registration be overridden with the component registry operations. +10 on this idea from me. The important thing would be to make sure the getToolByName deprecation message is smart enough to describe the exact necessary getUtility call. In other words use getToolByName(context, 'portal_properties') has been deprecated, please use getUtility(IPropertiesTool) instead rather than the confusing getToolByName has been deprecated, please use getUtility instead. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10 Sep 2006, at 14:53, Rocky Burt wrote: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFBA2rRAx5nvEhZLIRAhMEAJ4gelM/yEyqJEYx4mJ3ozsTSOf8yACcCMqh xlBPI4+Vt71pXyJp00zP5e4= =xpPv -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: On Sat, 2006-09-09 at 21:57 +0100, Martin Aspeli wrote: Hi guys, philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: actions = getUtility(IActionsTool) as another spelling for actions = getToolByName(context, 'portal_actions') But now we're being more consistent with Zope 3, we are using a proper interface and not just a string to check, we don't have to worry about passing a context parameter (though tests have to do a setSite() call), and we can let the registration be overridden with the component registry operations. +10 on this idea from me. +1 here, too. In fact, being able to make this switch is the *reason* 'getToolByName' was introduced in the first placey. The important thing would be to make sure the getToolByName deprecation message is smart enough to describe the exact necessary getUtility call. In other words use getToolByName(context, 'portal_properties') has been deprecated, please use getUtility(IPropertiesTool) instead rather than the confusing getToolByName has been deprecated, please use getUtility instead. I think we are likely to modify 'getToolByName' to use a registry of names to utility interfaces for all the known names, falling back to getattr only for unknown ones. In that case, the deprecation message can supply either the name of the interface, or at least say that the name is not a known tool name. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBBxJ+gerLs4ltQ4RAr6/AKCyhPoKGODtwUg5rVdo639YfbTeWACfcIt3 pZw9Eewu+EWXMhLvPKbajAg= =K23L -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi. Jens Vagelpohl wrote: Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? It was more of an edict, to catch up with the latest versions of our underlying frameworks again. The two things we are actually relying on right now is OOTB support for egg-enabled Python packages instead of Zope products (there are some egg-enabled plone.* and plone.app.* packages) and quite some of these packages are using the new local components API. We are also going to use formlib based forms, contentmanagers and viewlets and finally zope.testbrowser based tests but these are available in Zope 2.9 with Five 1.4 as well. Apart from these supporting only Zope 2.10 made it possible to remove quite some BBB code for changed package locations ;) As a final note I might add that we still consider to support Zope 2.11 as well for Plone 3.0 especially if it brings us Blob support on the ZODB level. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10 Sep 2006, at 14:53, Rocky Burt wrote: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? 2.10 really is lovely, because Zope 3.3 is lovely. :) The local components story is much, much better. Look at Hanno's GSLocalAddOns package (which really should move to CMFCore once CMFCore is happy to require 2.10+), or other examples. Basically, it solves a lot of the problems we had with 2.9 and earlier in that it was hard to make things installable into a CMF site - a global utility or adapter was an either-or proposition for all sites in a Zope instance. Being able to use local adapters (and local event handlers) is also very useful. Plus, the whole story around formlib, zope.contentprovider, zope.viewlet is improved, (these three tools are great - if you haven't played with them, go read the doctests, or Rocky's formlib tutorial on plone.org) and Five has caught up to these to make them accessible to us. Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
