[Zope-CMF] Re: Removing default from browser:skin layers?
Tres Seaver wrote: > Brent Hendricks wrote: > >>>Tres, >>> >>>I'm having trouble with the change you made today taking 'default' out >>>of the list of layers for the cmf browser:skin in >>>CMFDefault/skin/configure.zcml. It seems to cause the views we'e >>>defined in CMFPlone to no longer be found via the context/@@ lookup in >>>page templates. I added layer="cmf" to all of the plone view >>>declarations, but that didn't seem to work. >>> >>>Do you any ideas? In the meantime I defined a 'plone' skin that adds >>>default back in, but I'd prefer not to do that if it's not supported. > > > Likely my bad; its presence was causing test breakage when running on > 2.9, so I removed it, intending to investigate why. Let's put it back, > with a note in the ZCML documenting the fact that it needs to be checked > out. Any skin that wants to take advantage of all the elementary browser views (such as absolute_url, standard_macros, etc.) should include the 'default' layer because that's what all these views are registered for. Registering the Plone views for the 'default' layer is perfectly fine; in Zope 3 you don't need to create new layers for new packages because layers can be used across packages (unlike in the CMF). In my experience, Zope 3 layers are usually only used what they were made for: to customize existing views, IOW, to customize views in the 'default' layer. Tres, if you're experiencing the test failures with the Zope 2 trunk but not with Zope 2.8 branch, it might be because your stub request is lacking the 'default' layer. In Zope 3.1+, layers and skins are interfaces extending IBrowserRequest and they are directly provided on the request object by the skin machinery. Five tricks the Zope 2 request into providing the correct default skin interfaces with the following code in Traversable.__bobo_traverse__(): from zope.app.publication.browser import setDefaultSkin from zope.app.interface import queryType [snip] # set the default skin on the request if it doesn't have any # layers set on it yet if queryType(REQUEST, ILayer) is None: setDefaultSkin(REQUEST) In order to do deal with this (e.g. in tests) in both Zope 2.8 and 2.9 without resorting to ugly try/except clauses, Five could maybe grow a convenience function to do the above. It would do nothing in Five 1.2 and the above in 1.3. It would go away for Five 1.5. Let me know if this is the case, I'll be happy to put the function into Five and release new betas of 1.2 and 1.3. Philipp ___ 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: CMF 2.0 sandboxes
Tres Seaver wrote: > Tres Seaver wrote: > >>>yuppie wrote: >>> >>> >>> >Florent Guillaume wrote: > > > >>In what environement do people playing with CMF 2.0 (trunk) work ? >>Because when used with Zope 2 trunk, there are many failing unit tests. > > >My CMF 2.0 sandbox uses Zope 2.8.4 with Five 1.2. All tests pass on that >platform. I tried it once with Zope 2 trunk and also saw many failing >unit tests: > >1.) The 'default' layer is no longer available by default. That breaks >everything that depends on ZCML configuration. Removing it in >skin/configure.zcml 'fixes' most tests. >>> >>> >>>I don't know why that layer is gone on the trunk. It seems like a >>>needless BBB party foul. > > > The following ZCML imports get the default layer in place for 2.9, but > cause things to blow up on 2.8: > > $ svn diff > Index: CMFDefault/skin/configure.zcml > === > --- CMFDefault/skin/configure.zcml (revision 40195) > +++ CMFDefault/skin/configure.zcml (working copy) > @@ -8,6 +8,10 @@ >/> > > > + > + > + > + >name="cmf" >layers="cmf default" > > > Phillip, do you have a clue why Five's ZCML initialization order has > changed, such that the product ZCML is being done before the core zope3 > stuff? I think I know what's wrong. We're missing some important registrations of the default layer. I *think* we need the following declarations to be executed in Five.browser/configure.zcml: For that to work, we also need the 'defaultLayer' directive to be configured. I will try to fix this tomorrow, issue a 1.3b3 and include it into the Zope trunk. If anything else ain't working after that, my biggest suspicition would be the reason described in http://article.gmane.org/gmane.comp.web.zope.cmf/11066. G'night from Shanghai, Philipp ___ 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: CMF 2.0 sandboxes
Philipp von Weitershausen wrote: >>Phillip, do you have a clue why Five's ZCML initialization order has >>changed, such that the product ZCML is being done before the core zope3 >>stuff? > > I think I know what's wrong. We're missing some important registrations > of the default layer. I *think* we need the following declarations to be > executed in Five.browser/configure.zcml: > >interface="zope.publisher.interfaces.browser.ILayer" /> > >interface="zope.publisher.interfaces.browser.ISkin" /> > >interface="zope.app.publisher.interfaces.browser.IMenuItemType" /> > >type="zope.publisher.interfaces.browser.IBrowserRequest" > layer="zope.publisher.interfaces.browser.IDefaultBrowserLayer" /> > >interface="zope.publisher.interfaces.browser.IDefaultBrowserLayer" /> > > > For that to work, we also need the 'defaultLayer' directive to be > configured. I will try to fix this tomorrow, issue a 1.3b3 and include > it into the Zope trunk. Done. Just svn up your Zope 2.9 working copy. By the way, I noticed that CMFDefault registers a "cmf" layer and a skin under the same name. In Zope 3 we usually make layers all lower case (e.g. "some_layer_name") and skin names CamelCase (e.g. "SomeSkinName"). I think that convention was also roughly followed by CMF and CMF-based software; it would be good if CMF wouldn't deviate from it. Philipp ___ 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: Removing default from browser:skin layers?
Tres Seaver wrote:
> The error I am seeing is early, during product initialization, before
> any tests are actually running:
>
> File
> "/home/tseaver/projects/Zope-CVS/Zope-SVN-trunk/lib/python/zope/configuration/config.py",
> line 1390, in toargs
> args[str(name)] = field.fromUnicode(s)
> File
> "/home/tseaver/projects/Zope-CVS/Zope-SVN-trunk/lib/python/zope/configuration/fields.py",
> line 231, in fromUnicode
> raise InvalidToken("%s in %s" % (v, u))
> ZopeXMLConfigurationError: File
> "/home/tseaver/projects/CMF/cmf_test/z29_cmfhead/Products/CMFDefault/configure.zcml",
> line 5.2-7.6
> ZopeXMLConfigurationError: File
> "/home/tseaver/projects/CMF/cmf_test/z29_cmfhead/Products/CMFDefault/skin/configure.zcml",
> line 11.2-14.8
> ConfigurationError: ('Invalid value for', 'layers', "Couldn't import
> default, No module named default in cmf default")
> 2005-11-15 14:05:11 ERROR Zope Couldn't install Five
>
> That line in CMFDefault/skin/configure.zcml does:
>
>
>
> name="cmf"
> layers="cmf default"
> />
For the mailinglist archive:
This was a problem in Five 1.3b and 1.3b2. The 'default' layer wasn't
properly registered when Five was ported to Zope 3.2. This has been
fixed in Five 1.3b3 and the Zope 2.9 branch.
Philipp
___
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: Head-slot in five_template
Lennart Regebro wrote: > CMF 1.5 and 1.6 five_template (the one that provides a bridge between > zope3 and CMF templates) doesn't have a head-slot. I'm just wondering > if that slot is somewhat standard in Zope3 and CMF and not only CPS, > becuse it it is I'll add it. > > So? Is it? Zope 3's Rotterdam and Boston have: - title (on ) - headers (additional headers in ) - body(main content in a ) ZopeTop also has a 'head' slot for the whole element. Zope 3 style views in Five should use the same slots as they would in Zope 3, IMO. That means five_template would have to translate between Zope 3 slot names and CMF slot names. Philipp ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Rocky Burt wrote: > There is some logic regarding getting products-less python packages to > work as first class zope 2 products in a Five branch right now (once its > finished, its planned to be integrated into trunk for the Five 1.4 release). > > Hopefully this means Five 1.4 and CMF 1.6 will have the required changes > upon launch. But this means it will only support Zope 2.9. I've had > interest expressed in getting this backported so that it runs on Zope > 2.8 as well. Particularly since it would help the adoption of such > python-package-products happen *now* rather than 6-12 months from now. > So what I would like to do is: > 1) work on the latest version of Five supported on Zope 2.8 (Five 1.2 > svn branch) and provide the required functionality there +1 In an earlier thread I argued that this modified version of Five 1.2 should perhaps get a new name to indicate the additional feature. Do you all think that this would be feasible, or should we just go on with 1.2.1? If we give it a new name, the question is obviously which. 1.3 is already taken so we need some sort of suffix (a letter perhaps). Suggestions are welcome :). > 2) work on the latest version of CMFonFive supported on Zope 2.8 > (CMFonFive 1.2 svn branch) and provide a monkey patch for CMF 1.5 there. Why do we need to support CMF 1.5? CMF 1.6 works on Zope 2.8. The whole CMFonFive version dance confuses the heck out of me, we should try to keep things simple. Philipp ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Lennart Regebro wrote: >>CMFonFive version dance confuses the heck out of me, we should try to >>keep things simple. > > > Yes, I agree. So I think all of CMFonFive, including these changes, > should be in CMF 1.6. That ends the dance. It was a mistake to move > half of CMFonFive into CMF. We should have moved all of it in, and > called that 1.6 instead of 1.5.2 (but that's too late now). > > Doing this however, means that CMF 1.6 will NOT support Zope 2.8. I don't understand why that should be. It's also against everything that was decided when CMF 1.6 was started. Plone 2.5, for example, will use CMF 1.6 and wants Zope 2.8 compat. Philipp ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: >> In an earlier thread I argued that this modified version of Five 1.2 >> should perhaps get a new name to indicate the additional feature. Do you >> all think that this would be feasible, or should we just go on with >> 1.2.1? If we give it a new name, the question is obviously which. 1.3 is >> already taken so we need some sort of suffix (a letter perhaps). >> Suggestions are welcome :). > > > Ugh, soon we'll get Five 1.2-RC3-beta5-whatever. :) Hehe. > Are we really sure a further Five feature release for Zope 2.8 is > actually needed? What's happening with CMF and Plone in this regard? Is > Plone 2.5 still targeting Zope 2.8? Yes. > Is CMF? CMF 1.6 is. I hope CMF 2.0 is not. > I heard some mumblings perhaps 2.9 should be targetted. But perhaps > Zope 2.8 is still solidly the target. Perhaps these use cases aren't > driven by Plone/CMF core and some other packages would like to use > this in Zope 2.8? Can they be identified? The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. > For simplicity, both for the developers using Five as well as for the > developers building Five, it'd be much easier if we could simply all > agree new features go into Five 1.4 for Zope 2.9. Yes. I agree. I guess the only compelling reason to backport to Five 1.2 is to make people NOT upgrade to Zope 2.9 for this particular feature (product-less packages). Then again, Zope 2.9 is "stable" (people don't really trust a .0 release) and we could release Five 1.4 any time after Rocky is done. So there's really no reason for people NOT to upgrade, I guess. > Then again, I'm not absolutely against continuing the Five 1.2 line with > new features. Me neither. > How to name it is indeed tricky. Perhaps in favor of > comprehensibility we just want to name it 1.2.1, even though we add > new features. While we cheat and add new features to what should be a > pure bugfix release, potentially destabilizing it, I think it's > easier on everyone's mind not to introduce a new line of Five 1.2's > with features. Yes, on second thought I agree. > I also still hope that the pressure to add new features to Five 1.2 > will go away very quickly. Well, in five months we can retire Five 1.0 and 1.2 for good. I do not plan to maintain Five releases any longer than their corresponding Zope releases (others are welcome to do that, of course). Philipp ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Tim Hicks wrote: >>>The reason for doing so is simple: Products is bound to go away. It >>>gives a lot of people a lot of pain. With a lot of Zope 3 technology >>>entering many Zope 2 projects, it would be good to get a clean slate >>>early on: put new stuff on Product-less packages. >> >>You can turn that around; for consistency of installation experience in >>Zope 2.8, it's important that people don't get a new way of installing >>products, confusing innocent individuals installing Zope software. For >>the "cutting edge", Zope 2.9, that argument is slightly different. > > > Coming at this with a zope 2 head on, it seems to me that it might be > nice if I could carry on using the Products directory so that when I add > new 'products', I don't have to mix them in with the core zope code in > lib/python/. What do you mean by "core zope code"? Zope lives in SOFTWARE_HOME/lib/python, e.g. /usr/local/Zope-2.9.0/lib/python, your own python packages live in INSTANCE_HOME/lib/python, e.g. /var/zope/foobar.com/lib/python. > But the separation of 'core' and 'extras' gives me a comfortable > feeling. Is it just me? Am I just stuck in the past? I think you're just confusing software home vs. instance home. We're not making you put stuff into software home (although you can if you really want to... you can even put stuff into site-packages or anywhere you want as long as it's in PYTHONPATH). Plus, just the fact that stuff *being* somewhere in the PYTHONPATH doesn't mean it gets loaded. You have to add a ZCML slug to INSTANCE_HOME/etc/package-includes first. So, you could install a package globally and just make it available to certain instances by placing a slug or not. This is how package deployment works in Zope 3 and it's where we're heading with Zope 2 as well. See http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_01_11_mata-los-productos for further info and some ranting as well as constructive suggestions. Philipp ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Sidnei da Silva wrote: > On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: > | Then again, Zope 2.9 is "stable" (people don't really trust a .0 > | release) and we could release Five 1.4 any time after Rocky is done. So > | there's really no reason for people NOT to upgrade, I guess. > > There is at least one reason: People running python2.3 must switch to > python2.4 for Zope 2.9. That's somewhat painful, at least on > Windows. AFAIK installing multiple Python versions on Windows isn't a problem. Plus, doesn't Zope 2 ship with its own Python anyways? > I don't recall if OS X comes with Python 2.4 by default. Tiger ships with Python 2.3.5. However, compiling Python 2.4 from source is a piece of cake, let alone fink, darwinports or gentoo portage which provide the same kind of packaging capabilities to OSX as they do to Linux/Unix distributions. I haven't met a single developer who uses OSX and doesn't use at least one of those. And there's also MacPython which is a pointy-clicky installer for OSX; it's also available for Python 2.4, IIRC. Philipp ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: >>> Is Plone 2.5 still targeting Zope 2.8? >> >> Yes. > > > Yes to which question? Yes to "Is Plone 2.5 still targeting Zope 2.8". >>> Perhaps these use cases aren't >>> driven by Plone/CMF core and some other packages would like to use >>> this in Zope 2.8? Can they be identified? >> >> >> The general use case is to stop having to put things in Products. When >> now writing Zope 2 software, a lot of code basically expects stuff to be >> in Products, Rocky's modifications make that go away and add a ZCML >> directive to let Zope 2 pick up packages from outside Products (so that >> they will still receive the same initialization features and an entry in >> the Control_Panel, etc.). > > I know what the modifications allow you to do. > > It's a fundamentally different way of developing and installing > products. Therefore it's good to ask why we would want to expose such a > fundamentally new feature for Zope 2.8. Do we really want to start > explaining to people that "My product is special, you need to install it > like this, unlike what you're used to" when what we're dealing with is > not even the most recent stable release of Zope? > > To be clear: I realize that this effort is to make things *less* special > for Zope on the long term, and I support it's overall it with some > reservations, but we have to think about the tactical short term too. Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in the end you won't have to explain how to install Python packages at all because it's the same all the time... As somebody who's somewhat involved in Zope documentation, I am one of those above mentioned people. > For how long do we intend to evolve new features for what is not the > most recent stable release of Zope? I.e. we can make the argument that > this should be in the hands of the people soon for just about any new > feature in Five. Good point. > How urgent is it that all of this works with Zope 2.8? I guess it's > urgent if you want to sell it to the Plone community, which will only > switch to Zope 2.9 or beyond by next year or so, I expect. How much more > often is this kind of thing therefore going to happen? Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK they want time-based releases, 6 months apart like Zope. Just yesterday I suggested they make them 3 months off to the Zope releases. That way they can keep on track with Zope releases and not lag behind all the time. >> The reason for doing so is simple: Products is bound to go away. It >> gives a lot of people a lot of pain. With a lot of Zope 3 technology >> entering many Zope 2 projects, it would be good to get a clean slate >> early on: put new stuff on Product-less packages. > > > You can turn that around; for consistency of installation experience in > Zope 2.8, it's important that people don't get a new way of installing > products, confusing innocent individuals installing Zope software. For > the "cutting edge", Zope 2.9, that argument is slightly different. > > I want to identify the reasons why it is so important that this change > happens with Zope 2.8. The main reason I can identify is Plone, correct? I let Rocky take this one. I don't really feel strongly about having this available in Zope 2.8. Philipp ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Tim Hicks wrote: >>>Coming at this with a zope 2 head on, it seems to me that it might be >>>nice if I could carry on using the Products directory so that when I add >>>new 'products', I don't have to mix them in with the core zope code in >>>lib/python/. >> >>What do you mean by "core zope code"? Zope lives in >>SOFTWARE_HOME/lib/python, e.g. /usr/local/Zope-2.9.0/lib/python, your >>own python packages live in INSTANCE_HOME/lib/python, e.g. >>/var/zope/foobar.com/lib/python. > > Ah, ok, I think I am/was confused between INSTANCE_HOME and > SOFTWARE_HOME. Part of the confusion stems from me looking at the > directories that I have in my Zope 2.8.1 instance and seeing the following: > > [EMAIL PROTECTED] ~/zope/instance1 : ls -l > total 16 > drwxr-xr-x 2 tim2p tim2p 512 Sep 20 01:28 Extensions > drwxr-xr-x 47 tim2p tim2p 1536 Jan 15 23:20 Products > -rw-r--r-- 1 tim2p tim2p 410 Sep 19 21:44 README.txt > drwxr-xr-x 2 tim2p tim2p 512 Sep 19 21:44 bin > drwxr-xr-x 2 tim2p tim2p 512 Sep 19 21:44 etc > drwxr-xr-x 2 tim2p tim2p 512 Jan 11 10:48 import > drwxr-xr-x 2 tim2p tim2p 512 Dec 19 02:49 log > drwxr-xr-x 3 tim2p tim2p 512 Jan 16 12:14 var > > No lib/ (and therefore, no lib/python/) directory. Once I saw you guys > talking about lib/python/, I assumed you must have meant the one in > SOFTWARE_HOME. > > Presumably instances are going to grow a lib/python/ directory too. Yes. In fact, if one exists, it's automatically put on your PYTHONPATH for that instance. I think we should make Zope 2.8+ instance skeleta grow a lib/python directory. This can hardly be considered a feature, so we should be able to sneak it into the next bugfix releases of 2.8 and 2.9. > How > would that be different to just having those packages that appear in the > current (INSTANCE_HOME) Products/ directory just be directly importable > without the "Products." part in the import statement? I suppose > lib/python/ is more normal in the python world... Yeah, lib/python is a bit more normal (though it adds that extra path element which feels like clutter). Plus, your suggestion with a two-faced Products (once a PYTHONPATH container, once a top-level package) would make everything a bit ambiguous. Also, Products sort of acts as a namespace package. When we move to top-level packages, people might want to choose different namespace packages (e.g. Plone would hopefully choose 'plone' instead of 'CMFPlone' and the CMF might regroup everything under 'cmf', e.g. 'cmf.core', 'cmf.default', etc.) Philipp ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Sidnei da Silva wrote: > On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote: > | Sidnei da Silva wrote: > | > On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: > | > | Then again, Zope 2.9 is "stable" (people don't really trust a .0 > | > | release) and we could release Five 1.4 any time after Rocky is done. So > | > | there's really no reason for people NOT to upgrade, I guess. > | > > | > There is at least one reason: People running python2.3 must switch to > | > python2.4 for Zope 2.9. That's somewhat painful, at least on > | > Windows. > | > | AFAIK installing multiple Python versions on Windows isn't a problem. > | Plus, doesn't Zope 2 ship with its own Python anyways? > > Yes, the issue is not installing python, but packaging Zope. People > building installers for Windows have to have a MSVC > 7 and there > might be a significant amount of work involved on making all > dependencies of those installers work on Python2.4. True. Good point. But for how long do these people (I assume Enfold is one of them) plan to stick with Zope 2.8 then? I mean, they have to move forward at *some* point. Sure, it won't happen over night, but neither will Products-less packages in Zope 2... Philipp ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: > Just to comment on this interchange: Tim Hicks isn't the only one who > we'd need to explain a few things to in the new world order. We may end > up with people just dumping packages in SOFTWARE_HOME's 'lib/python' > directory if we're not careful. You're right, we haven't prepared people enough for this. I thank Tim for bringing this problem to my attention :). Being an advocate of lib/python (or at least the zope3ish way of doing extensions), I should take some responsibility here. First thing I'll do today is make sure Zope 2.8+ instances will have a lib/python dir with a proper README.txt. I will also write a blog entry. > I have some worries with the current Zope 3 world, as already expressed > in some earlier discussions with Philipp. There are right now too many > different ways people package their Zope 3 extensions. I know 2 different ways: INSTANCE_HOME/lib/python and site-packages. I think both are sensible and both should be easy enough to understand, even for brainwashed Zope2istas... Perhaps I'm missing other ways... Philipp ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Martin Aspeli wrote: >> How urgent is it that all of this works with Zope 2.8? I guess it's >> urgent if you want to sell it to the Plone community, which will only >> switch to Zope 2.9 or beyond by next year or so, I expect. How much >> more often is this kind of thing therefore going to happen? > > Zope 2.7 is now the officially supported shipped-with version of Plone > 2.1, but we also support Zope 2.8. Many products, including mine, > require Zope 2.8 (or usually only Zope 2.7 + Five). >From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over 2.8. Below you are suggesting that Plone 2.5 should do the same with Zope 2.8 (favouring it over 2.9). I don't understand why that should be. If one version has to be favoured at all, it should be the most recent one. That way it's made clear that the lower version (2.7, 2.8) is only still supported as a courtesy for those who don't want to upgrade right now. All other Plone developers and users should preferrably use the highest stable of Zope, otherwise Plone will continue to lag behind at least one Zope major release. > I believe the plan is to require Zope 2.8 and support Zope 2.8 for > Plone 2.5 in the same way. I don't really see the problem with this, > because Plone 2.5 won't use any of this stuff internally anyway - it's > only for add-on products. I have no problem requiring the users of my > products to upgrade to Zope 2.9. I would assume that those users who > want to use these new features either don't care, or are sophisticated > enough to find ways around any particular backwards/forwards > compatability problems they may have. > > So my vote is, leave Zope 2.8 alone if it's too much hazzle, and put > the effort into making sure Plone 2.5 runs flawlessly on Zope 2.9. That and make the upgrade from Zope 2.7/2.8 to 2.9 flawless as well as make 2.9 the *recommended* version for Plone 2.5. Then I don't think it should be much of a problem for Rocky to not have this available in 2.8, except perhaps if he wants to get started right now, with Plone 2.1 (though that might still run under Zope 2.9 and CMF 1.6, I hope). Philipp ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Alexander Limi wrote: > > From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over > > 2.8. Below you are suggesting that Plone 2.5 should do the same with > > Zope 2.8 (favouring it over 2.9). I don't understand why that should be. > > If one version has to be favoured at all, it should be the most recent > > one. That way it's made clear that the lower version (2.7, 2.8) is only > > still supported as a courtesy for those who don't want to upgrade right > > now. All other Plone developers and users should preferrably use the > > highest stable of Zope, otherwise Plone will continue to lag behind at > > least one Zope major release. > > Well, this depends on what release ships when. We made a decision not to > ship Zope 2.8.0 as the standard in the installers when shipping Plone 2.1 > - and that turned out to be a good choice, based on the number of problems > it had. > > I can guarantee you that Plone 2.5 will not ship with a Zope 2.9.0. A Zope > 2.9.(1|2|3) might be possible, but there's no way we are shipping a .0 > release of Zope with Plone. Once burnt, twice shy. :) There are indeed some issues to be sorted out with Zope 2.9 (Windows installer, premature zLOG deprecation, etc.), all of which aren't too big anymore, though. I think we can and should have a 2.9.1 bugfix release relatively soon. By looking at http://plone.org/products/plone/roadmap, Plone 2.5 will be out by 2006/05/08. By then Zope 2.9 can be considered stable and shippable I would say. Heck, by that time we'll already have a 2.10beta if I'm not mistaken. > > That and make the upgrade from Zope 2.7/2.8 to 2.9 flawless as well as > > make 2.9 the *recommended* version for Plone 2.5. Then I don't think it > > should be much of a problem for Rocky to not have this available in 2.8, > > except perhaps if he wants to get started right now, with Plone 2.1 > > (though that might still run under Zope 2.9 and CMF 1.6, I hope). > > What we ship in installers is one thing, what we personally use and > recommend is another. The installers will always be more conservative when > choosing versions. I can understand that reasoning. Fortunately, time-based releases will let us schedule these things in advance. E.g. by looking at the Plone 3.0 roadmap we can say that it will be relatively safe for it to depend and ship with Zope 2.10, coming out more than 3 months after the Zope 2.10 final release. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Martin Aspeli wrote: > > From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over > > 2.8. Below you are suggesting that Plone 2.5 should do the same with > > Zope 2.8 (favouring it over 2.9). I don't understand why that should be. > > If one version has to be favoured at all, it should be the most recent > > one. That way it's made clear that the lower version (2.7, 2.8) is only > > still supported as a courtesy for those who don't want to upgrade right > > now. All other Plone developers and users should preferrably use the > > highest stable of Zope, otherwise Plone will continue to lag behind at > > least one Zope major release. > > I'm not the release manager, so it's not my decision, but I think the > argument goes something like, Zope 2.9 hasn't lived very long, and .0 > versions of Zope have a history of having subtle security and performance > bugs; similarly, those who just upgraded to Zope 2.8 may not want to > upgrade again just yet. 2.8 is the conservative choice, for those who want > the most stable, out-of-the-box Plone. 2.9 will likely be the choice for > those who want the latest and greatest features from add-on products. Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... We will have to get used to the fact that Zope 2 release lines live shorter. They live for one year, to be exact. I think conservativism shouldn't extend beyond the age of Zope releases, unless the Plone people want to continue to maintain and release older Zope 2 versions on their own time. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: Reference Engine Componentization
whit wrote: > sorry for the cross post, but I know there are a number of other > reference engines out there and I would like to get input as we look > at moving the AT ref engine being a component. > > here is a rough list of steps: > > 1) move current storage of references to use IAnnotations for new > content / reference classes. Create a layer of indirection, making > reference storage a configurable option. > > 2) refactor UID storage to use IAnnotations I don't think neither references nor UID capabilities have to do with annotations. In fact, Zope 3 doesn't use annotations for either one: - UID capabilities: Zope 3 has the intid utility which allows one to assign any object a unique integer id. This should be adopted for Zope 2 and I think it would be fairly easy to do wrt persistent objects (as the ZODB is the same) - Extrinsic references: AT lets us add extrinsic references of one object to another. A Zope 3 implementation for this kind of references based on key references (zope.app.keyreference) is available in the ZC sandbox repository: http://svn.zope.org/Sandbox/zc/extrinsicreference/. With a bit of cleaning up and some docs I think it could very well become zope.extrinsicreference for Zope 3.3. Something that the CMF and Plone *could* start using annotations for is metadata such as DublinCore. In particular, every time some code is accessing DublinCore metadata, it should be changed to adapt to ICMFDublinCore first, even if that adaption might be a null-adaption for now (meaning, for now CMF content types always provide ICMFDublinCore). Note that ICMFDublinCore, despite its name, is part of Zope 3. > 3) implement IReferenceable to replace Referenceable mixin, implement >IReference to coexist with Reference class By "implementing" IReference / IReferenceable you probably don't mean the interface itself (there isn't much to implement) but the necessary adapter logic that lets us get rid of the mix-in. I think the default adapter should use the reference "engine" based on key references. Thank God we have GenericSetup coming along, otherwise the ZODB upgrade script would be pretty nasty ;) Philipp ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Andrew Veitch wrote: >> Let's put it this way: By the time Plone 2.5 is releases (if >> according to roadmap), Zope 2.8 is one month away from being >> *discontinued*. Conservative or not, I wouldn't bet on a release >> line that won't receive bugfixes the minute I start using it... > > Just so I'm clear, I've just checked the Plone 2.5 roadmap and it says > it is due in 8 May this year - is it really true that Zope 2.8 is going > to stop getting bugfixes in June this year? Yes. This was suggested by the Zope 2 release manager, Andreas Jung, two months ago: http://mail.zope.org/pipermail/zope-dev/2005-October/025554.html. Of course, other people are still welcome to backport fixes to the 2.8 branch and make releases themselves, but I suspect neither Andreas nor the Zope 2 developers will have the bandwidth to maintain more than three concurrent branches (Zope 2.9, Zope 2.10 and the trunk at that time). > I think for those of us deploying Zope on an enterprise scale it will > be pretty hard to do upgrades this frequently. I think one year is a pretty big span. Today, for example, you would not start a project on Zope 2.8. You would do it with Zope 2.9 which is going to get bugfixes until the end of 2006. Philipp ___ 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: [dev] CMF 2.0 browser views and Five traversal
yuppie wrote: > Based on the discussion on the Five list I propose this solution: > > 1.) To become independent of the lookup order views are named different > than the corresponding skin methods. > > 2.) Skins *and* views are always enabled. > > 3.) A new extension profile hooks up the views instead of the skin methods. This seems like an elegant solution. > Enabling Five traversal and views by default is a big change so we might > need an other beta release. I would strongly suggest that. > Some details: > > - I'd like to keep the changes the extension profile makes as small as > possible. So I don't want to change the visible action targets. All we > need are some Method Aliases that point to the views. > > - We need new names for the views. I'd like to use @@view.html, > @@edit.html and @@properties.html for the views that already exist. +1 for saner view names. "document_view" or "document_edit_form" is just a lame legacy from the one flat view namespace that portal_skins provide. By the way, unless you make @@view.html the default view name for documents or whatever (using five:defaultViewable and browser:defaultView), why not call it @@index.html?? Philipp ___ 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] Fighting the Zope 2.9 testrunner
Tres Seaver wrote: > I'm not sure what Chris meant, but the change to the visual output of > the testrunner when running "with dots" seems gratuitous to me, as well > -- I don't see any benefit to the "indented, narrower" output, Me neither, for what it's worth. > Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) > to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. Sort of. It didn't break configure && make. It's just "make install" that was broken. I still don't understand why people whine about "make install" being gone. The point of a checkout is that you have a full functional SVN working copy, not an installation source. If you want to install things, use a TGZ archive which lets you do "make install" perfectly fine. I've never installed Zope anywhere except on production servers anyway, and there you should obviously use releases. If you absolutely must use "make install" from a checkout (perhaps because you want to install the trunk somewhere), then you can make a TGZ first using zpkg. Though I still don't see the point of it. Philipp ___ 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: How do deal with cmfcatalog-wrapped objects?
yuppie wrote:
> Andreas Jung wrote:
>> we have a CMF-based application where I am trying to migrate from
>> TextIndexNG 2 -> 3.
>>
>> For a content-type class A I have configured an adapter to implement
>> IIndexableContent. However when the object is reindexed CMF wraps
>> the object as IndexableObjectWrapper which by itself implements
>> the IndexableObjectWrapper interface. The low-level indexer of TXNG
>> get the wrapped object and has no idea what to do with the object
>> since the interface of the wrapper shadows the interface of the
>> wrapped object.
>> Any idea how to deal with this problem?
>
> I'm currently fighting with the same issue. And I was in the process of
> writing a mail to the Zope-CMF list when your mail came in. AFAICS this
> is more a CMF issue than a Five issue, so I add Zope-CMF to the
> recipients list.
>
>
> Just for the records, I'm sure you already figured that out yourself:
>
> Plone 2.1 doesn't have this issue because it has no interface
> declaration on its ExtensibleIndexableObjectWrapper. If the wrapper
> doesn't have its own __providedBy__ attribute the __getattr__ method
> looks it up in the wrapped class, making the interface declarations
> completely transparent.
>
> Plone 2.5 has an interface declaration so I guess it has the same
> problem as the CMF.
>
>
> The quick and dirty solution would be to remove the interface
> declaration from the wrapper. The clean solution would be to make sure
> that all the interfaces that are actually provided - the wrapper
> interface *and* the interfaces of the wrapped object - can be looked up.
> But implementing that seems to require deeper knowledge of the interface
> machinery than I have.
This problem has already been solved in Zope 3. There we like to wrap
objects that don't provide ILocation (__parent__ and __name__
attributes) in something that *does* provide ILocation. The resulting
object is a proxy for the original object and in addition that it
provides __parent__ and __name__ attributes. The proxy provides whatever
the original object provides plus ILocation.
We call this concept a /decorator/. This is not to be confused with
Python 2.4's function decorators. In Zope 3's case, think of decorator
as a proxy that also adds stuff to the object (e.g. the ILocation API).
Hence, it decorates the original object, like a Christmas tree if you will.
There are two options:
1. I think for the long term, IndexableObjectWrapper could be made a
decorator. This works as follows:
from zope.proxy import getProxiedObject
from zope.app.decorator import Decorator
class IndexableObjectWrapper(Decorator):
def allowedRolesAndUsers(self):
ob = getProxiedObject(self)
allowed = {}
for r in rolesForPermissionOn(View, ob):
allowed[r] = 1
localroles = _mergedLocalRoles(ob)
for user, roles in localroles.items():
for role in roles:
if allowed.has_key(role):
allowed['user:' + user] = 1
if allowed.has_key('Owner'):
del allowed['Owner']
return list(allowed.keys())
2. In the short term we can apply the following trick
(IndexableObjectWrapper needs to be a new style class!):
from zope.interface import providedBy
from zope.interface.declarations import ObjectSpecificationDescriptor
from zope.interface.declarations import getObjectSpecification
from zope.interface.declarations import ObjectSpecification
class IndexableObjectSpecification(ObjectSpecificationDescriptor):
def __get__(self, inst, cls=None):
if inst is None:
return getObjectSpecification(cls)
else:
provided = providedBy(inst.__ob)
cls = type(inst)
return ObjectSpecification(provided, cls)
class IndexableObjectWrapper(object): # new-style!
implements(...) # it can implement as much as it wants
__providedBy__ = IndexableObjectSpecification()
...
This is obviously untested, but I'm pretty confident that this would work.
Philipp
___
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: How do deal with cmfcatalog-wrapped objects?
Andreas Jung wrote: > Both solution appear a bit "heavy" to me. I solved this issue for > TextIndexNG3 by adding generic support for wrapped objects by > introducing an IObjectWrapper interface which is checked by the > indexer. Using five:implements it is easy to attach this interface - > if necessary - to any wrapper class (including > [EMAIL PROTECTED]). Writing an adapter for adapting > IndexableObjectWrapper to IObjectWrapper is trivial. I think this > solution is more straight forward and does not require any changes to > the CMF. You are of course free to introduce adapters of your own, but I think the second solution suggested is not too heavy and easily implemented. After all, other code will also depend on the wrapper being as transparent as possible. Philipp ___ 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: SVN: CMF/trunk/CMFCore/ - fixed the unit tests that failed on Zope 2.10
Yvo Schubbe wrote: > Log message for revision 68396: > - fixed the unit tests that failed on Zope 2.10 > > (There is still one error, but that seems to be caused by a Zope bug.) Please file collector entries so that we know and eventually fix them. > +class Expression(Persistent): > > security = ClassSecurityInfo() > > def __init__(self, text): > self.text = text > -self._v_compiled = getEngine().compile(text) > +if text: > +self._v_compiled = getEngine().compile(text) May I suggest to make this test more robust for superfluous whitespace?: if test.strip(): self._v_compiled = getEngine().compile(text) > def __call__(self, econtext): > +if not self.text: > +return '' Same here... > Modified: CMF/trunk/CMFCore/tests/test_Expression.py > === > --- CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:10:52 UTC > (rev 68395) > +++ CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:18:49 UTC > (rev 68396) > @@ -49,21 +49,34 @@ > def test_anonymous_ec(self): > self.portal.portal_membership = DummyMembershipTool() > ec = createExprContext(self.folder, self.portal, self.object) > -member = ec.global_vars['member'] > +if hasattr(ec, 'contexts'): > +member = ec.contexts['member'] > +else: > +# BBB: for Zope 2.9 > +member = ec.global_vars['member'] Please file a collector issue for this BBB problem. Thanks Philipp ___ 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: SVN: CMF/trunk/CMFCore/ - fixed the unit tests that failed on Zope 2.10
yuppie wrote: > Philipp von Weitershausen wrote: >>> Log message for revision 68396: >>> - fixed the unit tests that failed on Zope 2.10 >>> (There is still one error, but that seems to be caused by a Zope >>> bug.) >> >> Please file collector entries so that we know and eventually fix them. > > Tres did that already: http://www.zope.org/Collectors/Zope/2117 Excellent. >>> Modified: CMF/trunk/CMFCore/tests/test_Expression.py >>> === >>> --- CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:10:52 >>> UTC (rev 68395) >>> +++ CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:18:49 >>> UTC (rev 68396) >>> @@ -49,21 +49,34 @@ >>> def test_anonymous_ec(self): >>> self.portal.portal_membership = DummyMembershipTool() >>> ec = createExprContext(self.folder, self.portal, self.object) >>> -member = ec.global_vars['member'] >>> +if hasattr(ec, 'contexts'): >>> +member = ec.contexts['member'] >>> +else: >>> +# BBB: for Zope 2.9 >>> +member = ec.global_vars['member'] >> >> Please file a collector issue for this BBB problem. > > I don't think this BBB issue has to be resolved in Zope. AFAICS > global_vars is not part of the API and CMF used it just for unit test > hacks. Just looked at the code. You're right. Philipp ___ 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: GenericSetup now incompatible with Zope 2.8?
yuppie wrote: > Jens Vagelpohl wrote: >> This checkin seems to have broken Zope 2.8-compatibility: >> >> http://svn.zope.org/GenericSetup/trunk/tests/common.py?rev=68391&r1=41338&r2=68391 >> >> >> Specifically, the line "from zope.testing.cleanup import cleanUp" >> breaks Zope 2.8, I checked all stable tags (2.8.5, 2.8.6, 2.8.7) and >> there is no toplevel name "cleanUp" in zope.testing.cleanup. >> >> DEPENDENCIES.txt still claims it works with Zope 2.8.5 and higher. One >> or the other needs changing, either DEPENDENCIES.txt needs updating >> or, if this breakage was inadvertently introduced, common.py needs >> fixing. > > Sorry, my mistake. I only tested against Zope 2.9 and 2.10 before > checking in. > > Should be fixed now: http://svn.zope.org/?rev=68474&view=rev Simply avoiding the cleanup in Zope 2.8 isn't a proper fix. You should instead do the following (which works across all Zopes): from zope.testing.cleanup import CleanUp CleanUp().cleanUp() ___ 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: CMF tests failing in zope 2.10
Florent Guillaume wrote:
> Some CMF 1.6 and 2.0 (and I guess trunk) tests are failing in Zope 2.10
> due to missing adapters somewhere. Example, when it tries to evaluate
> the path 'info/id' (where info is a dict):
>
> Error in test test_generateWorkflowXML_multiple
> (Products.DCWorkflow.tests.test_exportimport.WorkflowDefinitionConfiguratorTests)
>
> Traceback (most recent call last):
> ...
> File
> "/Users/fg/zope/zope2-zope/lib/python/Products/PageTemplates/Expressions.py",
> line 121, in _eval
> ob = self._subexprs[-1](econtext)
> File "/Users/fg/zope/zope2-zope/lib/python/zope/tales/expressions.py",
> line 124, in _eval
> ob = self._traverser(ob, element, econtext)
> File
> "/Users/fg/zope/zope2-zope/lib/python/Products/PageTemplates/Expressions.py",
> line 73, in boboAwareZopeTraverse
> request=request)
> File
> "/Users/fg/zope/zope2-zope/lib/python/zope/traversing/adapters.py", line
> 161, in traversePathElement
> raise TraversalError('No traversable adapter found', obj)
> TraversalError: ('No traversable adapter found', {'state_variable':
> 'state', 'state_info': [...], ...})
>
> Does anyone have an idea which adapters are missing, and where to add
> them in the tests?
Yup. I bet you just need to do
zope.component.provideAdapter(zope.traversing.adapters.DefaultTraversable).
The Zope 3 page template engine will use ITraversable adapters to
traverse just about anything. So, basically, wherever you're employing a
page template in CMF tests, you'll want this adapter.
Philipp
___
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: Effective use of effective_date and expiration_date
Raphael Ritz wrote:
> Tres Seaver schrieb:
> [..]
>>
>> Yep -- this is how the "typical" site uses those dates. However, some
>> folks want actual workflow transitions to happen ASAP after each date
>> passes. In that case, you need to write a periodic task which searches
>> for objects which are in the "between" state (e.g., their expiration
>> date has passed but they are still "active"), and cause the workflow
>> tool to "tickle" the transition machinery. E.g., as a Python Script::
>>
>> # untested
>> for brain in context.portal_catalog.searchResults(
>> review_state="published",
>> expiration_date={'query': ZopeTime(),
>> 'operator': 'max'}):
>> obj = brain.getObject()
>> wf_tool.doActionFor(ob, 'expire')
>>
>>
>
> Yep. And just reinforcing the obvious:
> Trigger the script Tres mentioned on a regular basis
> yourself, either using a cron job or Zope's ClockServer
> from Chris (included in Zope 2.10 now?)
>
> http://plope.com/software/ClockServer/
Yup, included.
___
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: CMF 2.1 release schedule
Jens Vagelpohl wrote: Jens mentioned that there still is a fair amount of outstanding work for 2.1; I'm hoping to be able to still use an alpha release with the current featureset. I was under the impression there were a few "show-stoppers" that needed CMF 2.1 (and in some cases Five) support that weren't there yet, like the "customize a skin item". Are there any items you know are missing? You seem to apply you have everything you need. Five will eventually get the "customize a template-based Zope 3 style view" story, but not before Five 1.6. In fact, to do this cleanly, some cleanup in Zope 3.4 would be nice (but not necessary). I plan to work on this at the Plone Conf sprints in Seattle, based on the experience and the prototype from the PyCON sprint. You guys should probably not take this as a show stopper for CMF 2.1. I'm not at all into CMF development, but it seems most of the items from the roadmap have indeed not been completed. So how is CMF 2.1 different from CMF 2.0 now? Looking at http://www.zope.org/Products/CMF/docs/roadmap there are quite a few items we were hoping to get in that aren't finished yet. By the way, the roadmap has the Five version numbers wrong. See http://codespeak.net/z3/five/INSTALL.html. Philipp ___ 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: [dev] writing tests for CMF 2.1
yuppie wrote: Since CMF 2.0 I did a lot of test refactoring, changing the ways CMF tests are set up. Goal was to use more generic and up to date testing patterns, making it easier to write new tests. Here is an overview what changed: ZopeTestCase.app() -- All tests that depend on a running Zope application use now ZopeTestCase's ZopeLite app. It is not compatible with Zope2.app(), so don't use Zope2.app() anymore. ZopeLite doesn't start up Products by default, you have to specify required Products explicitly using ZopeTestCase.installProduct(). Not each Product has to be initialized that way. Don't initialize Five that way - ZCML is set up differently. Layers -- ZCML is set up using test layers. Their setUp() and tearDown() methods are only run once for all tests in the layer. Who! -- http://worldcookery.com -- Professional Zope documentation and training ___ 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] How to run CMFCore 2.0 tests?
Hi there,
while forward-porting the fix for http://www.zope.org/Collectors/CMF/459
from 1.6 to 2.0, I was running the tests for CMFCore 2.0 and was getting
tons of failures with a straight checkout (see attached file). Is there
anythign I'm missing?
Philipp
--
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
$ bin/zopectl test -s Products.CMFCore
Running tests via: /opt/local/bin/python /usr/local/Zope-2.9.6/bin/test.py -v
--config-file .../etc/zope.conf -s Products.CMFCore
Parsing .../etc/zope.conf
Running tests at level 1
Running unit tests:
Running:
Error in test test_normal
(Products.CMFCore.exportimport.tests.test_catalog.exportCatalogToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 86, in __call__
self.setUp()
File ".../Products/CMFCore/exportimport/tests/test_catalog.py", line 110, in
setUp
Products.GenericSetup.PluginIndexes)
AttributeError: 'module' object has no attribute 'PluginIndexes'
.
Error in test test_unchanged
(Products.CMFCore.exportimport.tests.test_catalog.exportCatalogToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 86, in __call__
self.setUp()
File ".../Products/CMFCore/exportimport/tests/test_catalog.py", line 110, in
setUp
Products.GenericSetup.PluginIndexes)
AttributeError: 'module' object has no attribute 'PluginIndexes'
.
Error in test test_empty_purge
(Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 86, in __call__
self.setUp()
File ".../Products/CMFCore/exportimport/tests/test_catalog.py", line 110, in
setUp
Products.GenericSetup.PluginIndexes)
AttributeError: 'module' object has no attribute 'PluginIndexes'
.
Error in test test_empty_update
(Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 86, in __call__
self.setUp()
File ".../Products/CMFCore/exportimport/tests/test_catalog.py", line 110, in
setUp
Products.GenericSetup.PluginIndexes)
AttributeError: 'module' object has no attribute 'PluginIndexes'
.
Error in test test_normal_purge
(Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 86, in __call__
self.setUp()
File ".../Products/CMFCore/exportimport/tests/test_catalog.py", line 110, in
setUp
Products.GenericSetup.PluginIndexes)
AttributeError: 'module' object has no attribute 'PluginIndexes'
.
Error in test test_normal_update
(Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 86, in __call__
self.setUp()
File ".../Products/CMFCore/exportimport/tests/test_catalog.py", line 110, in
setUp
Products.GenericSetup.PluginIndexes)
AttributeError: 'module' object has no attribute 'PluginIndexes'
.2006-12-07 23:06:41 WARNING ZODB.DB DB.open() has 8 open
connections with a pool_size of 7
.
Error in test test_body_set
(Products.CMFCore.exportimport.tests.test_skins.SkinsToolXMLAdapterTests)
Traceback (most recent call last):
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py",
line 260, in run
testMethod()
File ".../Products/GenericSetup/testing.py", line 98, in test_body_set
adapted.body = self._BODY
File ".../Products/GenericSetup/utils.py", line 515, in _importBody
self._importNode(dom.documentElement)
File ".../Products/CMFCore/exportimport/skins.py", line 106, in _importNode
self._initObjects(node)
File ".../Products/GenericSetup/utils.py", line 574, in _initObjects
raise ValueError("unknown meta_type '%s'" % meta_type)
ValueError: unknown meta_type 'Filesystem Directory View'
...
Error in test test_fragment3_skip_purge
(Products.CMFCore.exportimport.tests.test_skins.importSkinsToolTests)
Traceback (most recent call last):
File "/usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py",
line 98, in __call__
testMethod()
File ".../Products/CMFCore/exportimport/tests/test_skins.py", line 557, in
test_fragment3_skip_purge
importSkinsTool(context)
File ".../Products/CMFCore/exportimport/skins.py", line 213, in
importSkinsTool
importObjects(tool, '', context)
File ".../Products/GenericSetup/utils.py", line 754, in importObjects
importer.body = body
File ".../Products/GenericSetup/utils.py", line 515, in _
[Zope-CMF] Re: How to run CMFCore 2.0 tests?
Jens Vagelpohl wrote: while forward-porting the fix for http://www.zope.org/Collectors/CMF/459 from 1.6 to 2.0, I was running the tests for CMFCore 2.0 and was getting tons of failures with a straight checkout (see attached file). Is there anythign I'm missing? I notice you're only running CMFCore tests, which I never did on that branch. I just use "zopectl test" and all tests run, the only failures are 3 CMFCalendar tests. Those have to do with the recent DateTime changes that introduced a non-backwards compatible time string parsing problem, if I remember correctly Stefan Holek assigned that one to himself in the Zope collector, but nothing has happened so far. Can you try running all tests at once? Yes, that worked, except for those 3 CMFCalendar tests... Thanks. -- 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: How to run CMFCore 2.0 tests?
Jens Vagelpohl wrote: P.S.: This problem does not occur on the trunk. I'll blame Yvo for the clean run on the trunk ;) Yes, I was quite (positively) baffled by how nicely the tests run on CMF, using layers and all that. Kudos to Yvo! -- 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: Fwd: [Checkins] SVN: CMF/branches/1.6/C CMFCore.DynamicType: Fixed behaviour regarding default view.
Stefan H. Holek wrote: CMF 1.6 is supposed to work with Zope 2.8. Aha. Yuck. :) However, either there is no queryDefaultViewName or it lives someplace else... from zope.app.publisher.browser import queryDefaultViewName ImportError: cannot import name queryDefaultViewName All fixed now... -- 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: [CMF 2.1] FSPageTemplate & Unicode
On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
Okay, spoke to Philipp on IRC and he asked me to relay his opinions
on some of this:
- CMF tools ought not to depend on acquiring things from 'self' if
at all possible.
- TTW code will need aq contexts for security. However, it makes
sense for getToolBy(Interface)Name() to handle this.
- Non-TTW code probably shouldn't need aq contexts.
- Registering the portal as a utility that can be obtained by
getUtility(IPortalRoot) is pretty good practice; in my estimation,
that should solve all the use cases for utilities where acquisition
is used now and where we're not really after an adapter, view.
- Using component registries would be bad in terms of maintenance;
in my own opinion, aq-wrapping when it may not be needed may lead
to headaches later as well.
Also, in my own opinion, why don't we keep getToolByName() (since
it's so incredibly prevalent) and just let it handle dotted
interface names as well? The chances of a name clash are minute,
and we can at a later stage deprecate the non-dotted names. I say
this because (a) getToolByInterfaceName() is long :) and (b) it's
one more thing to remember and (c) everyone's already using
getToolByName().
Actually, why dont you keep a simple mapping between existing names
and interfaces, e.g.:
name2iface = {'portal_catalog': ICatalog,
'portal_skins': ISkinTool,
...}
and use that in getToolByName? Then *all* of the existing code base
continues to work, especially if getToolByName does aq wrapping.
getToolByName('some.dotted.interface.IName') looks silly.
___
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: [CMF 2.1] FSPageTemplate & Unicode
Hanno Schlichting wrote: Martin Aspeli wrote: Hanno Schlichting wrote: PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Philipp also has some ideas (not too far off completion, I believe) that may remove some of the acquisition intermingling. I'm not sure they'd apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) I still do as I haven't found much time to work on this further. I'm looking for someone to take over my branch (knowledge of Python C API and experience with debugging C code required). I consider this a crucial step in moving forward. Acquisition is really getting in the way now and having the simpler __parent__ API be supported as an alternative in Zope 2 would simplify things a lot -- also in this case. Alas, I'm running out of time and experience with this stuff. :( -- 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] [CMF 2.1] PersistentComponents is not enough
Hi there, others and I have been pushing the usage of local components in Five. As a result it looks like the CMF 2.1 will use the CA to look up its tools. Woohoo! (Kudos to Jens and all the others!) There's one problem with all this which I admit I have failed to communicate better (certain key players know this for some time, but haven't spoken up either): Using PersistentComponents() as the component registry (a.k.a. site manager) for local sites isn't enough. That's because it doesn't understand about containment hierarchies. Imagine this folder hierarchy: /root_site/ + cmf_site/ + somefolder/ + anotherfolder/ + sitefolder/ + + stuff_in_here "cmf_site" is obviously a site. Let's say "root_site" and "sitefolder" are also sites (yes, Zope3-style sites can be nested). That's not to say that sitefolder is another CMF Site, it's just a Zope3-style ISite (regular zope 2 folders can be sites in Zope 2.10). You would expect component lookup at "stuff_in_here" to * first lookup stuff in "sitefolder", * then in "cmf_site", * then in "root_site", * and finally in the global registry If you use PersistentComponents() this won't automatically happen! Component registries have an __bases__ attribute which contains the next site manager in the in the lookup chain. Currently, we stub this out by simply putting the global registry in __bases__ and nothing else. The code that does this looks like that (this is from Jens's branch): components = PersistentComponents() components.__bases__ = (base,) # base is the global registry site.setSiteManager(components) With such component registries in place at each "sitefolder", "cmf_site" and "root_site", component lookup will never cascade the way we intiutively would expect it from acquisition. So, how do we fix this? Obviously, the __bases__ attribute of site_folder's component registry must contain cmf_site's component registry and NOT the global one. cmf_site's registry in turn must refer to root_site's registry etc. Simple enough. It's really all about setting the right __bases__. The tricky part is that this whole "linked list" of site managers needs to be updated when * new sites are created somewhere in a hiearchy (e.g. root_folder used to be not a site, and now you turn it into one, then cmf_site's __bases__ should be updated to refer to the root_folder registry instead of the global one) * sites get moved around, e.g. to places where you have a site higher in your parent hierarchy. In Zope 3 already has code that deals with those things. It's a subclass of PersistentComponents called LocalSiteManager (zope.app.component.site). It figures __bases__ out itself based on the containment hierarchy (in Zope 3 that's __parent__). LocalSiteManager is also a container (similar to a folder) so that local persistent components can be placed inside it instead of in the site object itself which normally contains only content objects. Usually the URL name of the site manager is ++etc++site, e.g. /cmf_site/++etc++site would be the site manager of cmf_site. We need a LocalSiteManager implementation for Zope 2 (mostly because of the __bases__ thing, but perhaps also because we then have a designated place for local components instead of the portal root). The Zope 2 version of LocalSiteManager should subclass PersistentComponents and then use Zope3's LocalSiteManager's approach to update __bases__ in the above mentioned cases. Zope 3's LocalSiteManager code contains some cruft that isn't needed in Zope 2. We really only need the __bases__ stuff (part of which is a subscriber for ObjectMovedEvent which needs to be adapted for Zope 2 as well). The most obvious difference is that the Zope 2 version of LocalSiteManager should use acquisition instead of __parent__ pointers to determine the containment hierarchy. As a bonus, the Zope 2 LocalSiteManager could also mix in ObjectManager. Since Five is feature-frozen and new stuff should be added in Python packages anyway, my suggestion is to put this thing into a five.localsitemanager package which would then be used by CMF 2.1, Plone 3, etc.. It could possibly be included into the Zope 2.11 release. I'd like to avoid making a Five 1.6. Philipp -- 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: [CMF 2.1] FSPageTemplate & Unicode
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 8 Jan 2007, at 01:19, Hanno Schlichting wrote: Right now I would let all existing CMF tools implement that interface, so we would be on the safe side. In a later release we can revisit this and see if some tools don't need Acquisition to work properly. If I'm not mistaken this should let us remove all the manual AQ- wrapping again (sorry Jens for the premature patch) and thus impose no extra pain on add-on developers. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. Even in Zope3, I think that "local" utilities may need to be local, meaning that they know the "place" in which they are registered. No they don't. There's nothing implied for local utilities, not even persistence. Of course, many local utilities *are* persistent and stored in a folder somewhere, thus have a __parent__ and all that. But that's typically less of interest when *using* the utility. In Zope2, we *must* wrap them for the sake of security, if nothing else. Sadly yes. -- 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: [CMF 2.1] PersistentComponents is not enough
On 8 Jan 2007, at 17:30 , Rocky Burt wrote: On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote: Using PersistentComponents() as the component registry (a.k.a. site manager) for local sites isn't enough. That's because it doesn't understand about containment hierarchies. Imagine this folder hierarchy: /root_site/ + cmf_site/ + somefolder/ + anotherfolder/ + sitefolder/ + + stuff_in_here "cmf_site" is obviously a site. Let's say "root_site" and "sitefolder" are also sites (yes, Zope3-style sites can be nested). That's not to say that sitefolder is another CMF Site, it's just a Zope3-style ISite (regular zope 2 folders can be sites in Zope 2.10). You would expect component lookup at "stuff_in_here" to * first lookup stuff in "sitefolder", * then in "cmf_site", * then in "root_site", * and finally in the global registry If you use PersistentComponents() this won't automatically happen! This is a major problem. This means that if someone is traversing to sitefolder and some view code calls getUtility(ICatalog) (instead of the deprecated getToolByName(context, 'portal_catalog') then the lookup will fail if sitefolder doesn't provide the utility (and it probably won't provide it). Right. Since Five is feature-frozen and new stuff should be added in Python packages anyway, my suggestion is to put this thing into a five.localsitemanager package which would then be used by CMF 2.1, Plone 3, etc.. It could possibly be included into the Zope 2.11 release. This would be the best approach (creating five.localsitemanager) in my opinion. But, this means CMF will either require (or distribute) five.localsitemanager. (Plone will have the same issue) I'm not sure where we stand on this. Me neither. I'd just like to avoid that either CMF or Plone or both grow their own implementations. The problem is completely generic to Zope 2, hence we should have an independent package. If we must (because Plone and CMF havne't figured out their egg story yet), then I guess we can make a Five 1.6 (which would be a fork of Five 1.5; the current Five trunk has no version number anymore as it'll be integrated into the Zope trunk). I'd like to avoid making a Five 1.6. +1 ___ 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: [CMF 2.1] PersistentComponents is not enough
Jens Vagelpohl wrote: CMF won't come eggified for this release, that work has stalled. whit wrote: plone's egg story looks non-existent until next release. Right, I figued as much. Also, it's only for Zope 2.11 that we can actually tackle sensible egg support in the Zope 2 core, so that makes more sense anyway. I see three options: a) somehow bundle CMF 2.1 (and Plone 3) with a package called five.localsitemanager. Given that Plone 3 already has plone.* packages (and I assume they also want five.customerize), this might probably be less of an issue for Plone than for the CMF. b) make Five 1.6 and have that include five.localsitemanager. I would *rather* not like to do that... c) create Products.FiveLocalSiteManager, or perhaps Products.LocalSiteManager. Yet another product *sigh*. OTOH, that might not be such a problem since I envision products to become eggs in Zope 2.11... -- 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: [CMF 2.1] PersistentComponents is not enough
Philipp von Weitershausen wrote: Jens Vagelpohl wrote: CMF won't come eggified for this release, that work has stalled. whit wrote: plone's egg story looks non-existent until next release. Right, I figued as much. Also, it's only for Zope 2.11 that we can actually tackle sensible egg support in the Zope 2 core, so that makes more sense anyway. I see three options: a) somehow bundle CMF 2.1 (and Plone 3) with a package called five.localsitemanager. Given that Plone 3 already has plone.* packages (and I assume they also want five.customerize), this might probably be less of an issue for Plone than for the CMF. b) make Five 1.6 and have that include five.localsitemanager. I would *rather* not like to do that... c) create Products.FiveLocalSiteManager, or perhaps Products.LocalSiteManager. Yet another product *sigh*. OTOH, that might not be such a problem since I envision products to become eggs in Zope 2.11... Of course, whatever we decide to do, the result really should ship with Zope 2.11. It's already sort of a crime that we don't do this in Zope 2.10 yet. Even worse, Five itself is creating sites w/ PersistentComponents :(. -- 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: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: Dieter Maurer wrote: Martin Aspeli wrote at 2007-1-7 23:40 +: ... Why not do it a more Zope3 ish way: class ICMFTool(Interface): """Marker for any CMF tool""" and then in the subclass of the local component registry: local_utility = if ICMFTool.providedBy(local_utility): local_utility = local_utility.__of__(context) or so. No need to invent a new marker interface for this. Objects ready to participate in context wrapping indicate this by the "__of__" method... No, no need, but I'd argue good reasons. - It's an explicit declaration of support - It's a lot less magic - It's prettier than getattr/hasattr - If something else has an __of__() for whatever reason, we don't catch it by accident. - It may not be desirable to wrap everything that *could* be wrapped. Actually, I agree with Dieter here. If something has an __of__(), just wrap it. You can't possibly do anything wrong, actually, as it already happens and it provides the best backward compatibility with what we have right now. Once we support __parent__ pointers, we can phase out the wrapping. We can do that by making less and less objects have those __of__() methods for example. -- 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: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: Philipp von Weitershausen wrote: Actually, I agree with Dieter here. If something has an __of__(), just wrap it. You can't possibly do anything wrong, actually, as it already happens and it provides the best backward compatibility with what we have right now. Is __of__() in an interface somewhere? I would prefer using that (if it's promised by some mixin deep in zope anyway). Not that it greatly matters, if we actually want a policy that wraps every time. If we want wrapping to be controllable and optional, I think we need a marker interface. Fair enough, __of__() is documented by Acquisition.interfaces.IAcquirer which is provided by all objects inheriting from Aquisition.Explicit or .Implicit. That's your marker interface. -- 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
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',
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: Adding python packages to ProductsPath
Wichert Akkerman wrote:
At the moment it is not possible to use skin layers in pure python
packages. This is caused by the DirectoryView implementation using
a minimal path name for the layer id. This path name is created
by CMFCore.utils.minimalpath, which uses the ProductsPaths list of
directories to look for the filesystem directory and uses an absolute
path if it can't find it. Since this absolute path will differ per
install you can't use it in something like genericsetup profiles.
The patch below fixes this by adding $INSTANCE_HOME/lib/python to the
ProductsPaths list. This allows minimalpath to find python packages installed
there.
Are there any objections to commiting this to trunk?
I don't have any actual objections, but I find looking at
Products.__path__ a bit lame and way too close-minded, to be honest.
Your suggested addition doesn't make it better since you're broadening
the scope just a little bit. What about packages installed somewhere
else than instance/lib/python? The idea of using Python packages, after
all, is that they can be installed *anywhere* on the PYTHONPATH. The
whole thing would already break if a package would be installed as an
egg, even it was installed into lib/python.
The Right Thing(tm) IMO would be look at Zope's own products registry
and inspect that for directories in which to look for skins. This would
also be a future proof solution should
http://wiki.zope.org/zope2/EggifyingZopesExtensionMechanismQuotProductsQuot
be implemented.
Philipp
Index: utils.py
===
--- utils.py(revision 72192)
+++ utils.py(working copy)
@@ -719,8 +719,10 @@
return os_path.normpath(p.replace('\\','/')).replace('\\','/')
import Products
-ProductsPath = [ abspath(ppath) for ppath in Products.__path__ ]
+ProductsPath = [ abspath(ppath) for ppath in Products.__path__ ] + \
+[ os_path.join(INSTANCE_HOME, 'lib', 'python') ]
+
security.declarePublic('expandpath')
def expandpath(p):
""" Convert minimal filepath to (expanded) filepath.
--
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
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
[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
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: Internationlisation question
Charlie Clark wrote:
Zope 3 provides all sorts of localization functionality, including
numbers, currency and calendaring.
Look in zope.i18n.locales ...
Yes, I can see what's there but I do not seem to be able to call it from
a page template. If I try the following example from
http://wiki.zope.org/zope3/ZPTInternationalizationExamples
Based on what the id specifies, the date time object is returned in
typical German format: Montag, 1. Januar 2001 (example)
This is quite outdated. It doesn't surprise me you're getting an error here.
Like Jean-Francois said, zope.i18n.locales has some good support for
formatting datetime values (the Python variant, not Zope's DateTime
variant). In Zope 3, this functionality is available through
request.locale. In Zope 2, you will have to create the locale object
yourself like so:
from zope.i18n.interfaces import IUserPreferredLanguages
from zope.i18n.locales import locales
languages = IUserPreferredLanguages(request)
langs = languages.getPreferredLanguages()
if langs:
parts = (langs[0].split('-') + [None, None])[:3]
else:
parts = (None, None, None)
locale = locales.getLocale(*parts)
Then you can format datetimes such as the 'modified' variable in the
below example like so:
Last modified on
My book explains all of this in detail. I suggest picking up a copy :)
--
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: Five's local sitemanager, CMF, etc
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli <[EMAIL PROTECTED]> wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would just mean
aq_base'ing the utility and aq-wrapping it back into the context (the
portal root). Without this, we start requiring users of the interface to
know when aq wrapping is needed and do it explicitly with __of__() which
I think we agreed was unacceptably detailed and ugly. :)
Alright, I've gone ahead and put code in place for this (albeit a bit
naively) with r72810. The next question is whether we should be doing
the same with adapters and subscribers as well (even though this
doesn't affect the whole tools-getting-acquired-properly issue).
I'm a bit uneasy about the implementation. With
Acquisition.ImplicitAcquisitionWrapper(base, parent) it seems you're
wrapping all utilities, even those that don't inherit from acquisition
and potentially don't want acquisition. Even worse, you give them an
*implicit* acquisition wrapper.
I think _wrap() should be changed to:
def _wrap(self, comp):
"""Return an aq wrapped component with the site as the parent.
"""
if Acquisition.interfaces.IAcquirer.providedBy(comp)
parent = Acquisition.aq_parent(self)
if parent is None:
raise ValueError('Not enough context to acquire parent')
base = Acquisition.aq_base(comp)
comp = base.__of__(parent)
return comp
This way, only objects that inherit from one of the Acquisition base
classes will be wrapped at all.
--
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: Five's local sitemanager, CMF, etc
Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli <[EMAIL PROTECTED]> wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. -- 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: Five's local sitemanager, CMF, etc
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli <[EMAIL PROTECTED]> wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is "crying wolf", IMNSHO. I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. -- 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: Five's local sitemanager, CMF, etc
On 26 Feb 2007, at 23:48 , Tres Seaver wrote: I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. OK. I do think we need to have some resistance to the "Zope2 is evil, Zope3 is wonderful" fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of the scenarios Zope2 does, and maybe never will. Yes. Zope 3 is can be seen as a set of libraries -- and a number of approaches. As far as acquisition (the concept) is concerned, I think the common perception is that Acquisition (the Zope 2 package) introduces pains, magic and unpredictability, whereas the way acquisition is implemented in Zope 3 (discrete places called sites from which you can acquire things after registering things explicitly) is a cleaner and more predictable concept. I see this whole effort (making CMF tools available as utilities, etc.) a way to move from Acquisition (the Zope 2 package) to a better form of acquisition (using the Zope 3 Component Architecture). Such a process needs to be accompanied by clear statements what's encouraged and what's discouraged. That doesn't mean that the old way is "evil", but we can certainly give a clear recommandation as to what's better (not necessarily "wonderful" but better). To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. I'll note that five views are already required to be acquisition wrapped if they use any objects protected by Zope2 security machinery. Yes, but their wrapping is a detail of the traversal and security machinery. Hence it happens during traversal, not during component lookup. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. I don't know of such a distinction. Please explain how one registers a "subscription adapter". registry.registerSubscriptionAdapter() More on subscribers vs. subscription adapters: * "Subscribers" are the event subscribers we know: simple callables. They don't return anything (well, they return None :)), hence there's nothing to wrap or anything. * "Subscription adapters" are like regular adapters (and they are implemented exactly like a regular adapter). The difference is in the lookup. Instead of getting exactly 0 or 1 adapter in the adaption, you get n adapters (where n=0,1,2,3...) with subscription adapters. Basically, instead of finding the most specific adapter, subscription adapters will return *all* applicable adapters. So their lookup is a bit like the one of subscribers, hence the name. ___ 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-utilities, merging, releasing, etc
Sidnei da Silva wrote: That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. Yes, the ZPublisher should be firing it. But it doesn't. While it's clearly an oversight for Zope 2.10, I wonder if it can be classified as a bug or not. Probably not. Certainly a lot of existing Zope 2 ISites will have this hideous persistent before-traverse hook that came to us via whoever thought of Five.site (*cough* right, Sidnei? :)). So if the ZPublisher introduces this event, we'll ahve to be careful that it won't be sent twice for an object... Patches are welcome :). -- 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: getUtility(ISiteRoot) bug?
yuppie wrote: portal = getUtility(ISiteRoot) I can't get this working. The lookup from within getExprContext fails. But: - sm.registeredUtilities() contains the ISiteRoot registration Is 'sm' actually the current site manager? Try to compare whether z.c.getSiteManager() matches 'sm'. - if I first call getUtility(ISiteRoot) from somewhere else, the lookup doesn't fail in getExprContext either (I guess the result of some caching) -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: Delete trouble
Martin Aspeli wrote:
Traceback (innermost last):
Module ZPublisher.Publish, line 119, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 42, in call_object
Module OFS.ObjectManager, line 524, in manage_delObjects
Module OFS.ObjectManager, line 379, in _delObject
Module zope.event, line 23, in notify
Module zope.component.event, line 26, in dispatch
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module zope.component.event, line 33, in objectEventNotify
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module OFS.subscribers, line 108, in dispatchObjectWillBeMovedEvent
Module zope.app.container.contained, line 182, in dispatchToSublocations
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module OFS.subscribers, line 108, in dispatchObjectWillBeMovedEvent
Module zope.app.container.contained, line 182, in dispatchToSublocations
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module Products.CMFCore.CMFCatalogAware, line 285, in
dispatchToOpaqueItems
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module Products.CMFCore.CMFCatalogAware, line 306, in
handleOpaqueItemEvent
Module Products.CMFUid.UniqueIdAnnotationTool, line 87, in
manage_beforeDelete
Module zope.component._api, line 207, in getUtility
ComponentLookupError: (Products.CMFUid.interfaces.IUniqueIdAnnotationManagement>, '')
The UniqueIDAnnotationTool should probably do a *query*Utility (which
will return None in case the utility can't be found) and simply not do
anything in such a case. The canonical way of expressing such fail-safe
routines is therefore:
component = query{Utility|Adapter|MultiAdapter}(...)
if component is not None:
...
--
http://worldcookery.com -- Professional Zope documentation and training
___
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: Delete trouble
Martin Aspeli wrote:
The UniqueIDAnnotationTool should probably do a *query*Utility (which
will return None in case the utility can't be found) and simply not do
anything in such a case. The canonical way of expressing such
fail-safe routines is therefore:
component = query{Utility|Adapter|MultiAdapter}(...)
if component is not None:
...
I agree, except I think there could potentially be lots of places where
this could be happening.
Indeed.
In the general case, it's probably safe for
that code to assume the utility is there, and treat it as an error if
it's not,
I disagree. Componentized code gains maximum reusability if it assumes
as little as possible about the setup and other components, other than
what interfaces promise (defensive programming). I bet that a lot of
places where the UniqueIDAnnotationTool is looked up, it's all about
updating the some information and if the tool ain't there, then I think
it's safe to simply skip that step. Code that directly needs the
UniqueIDAnnotationTool to do its job will have to assume that it can get
the utility, but all other code shouldn't have to.
but during site deletion, it is probably at the mercy of the
order of deletions. At least that's my guess.
It might be at the mercy of event subscriber execution order, but it's
really the site traversal issue I think:
It *could* also be a site manager/traversal issue, I guess - I'm one
level above the Plone site when I delete this, so possibly it's not
finding the right site manager? Not sure how that works...\
*sigh* Chapter XYZ in my book explains the process :). Whenever you
traverse over a site, its site manager becomes the active component
registry. So if you haven't traversed over that site yet, the utilities
in that site won't be found. It's that simple.
--
http://worldcookery.com -- Professional Zope documentation and training
___
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: Delete trouble
Martin Aspeli wrote: Philipp von Weitershausen wrote: *sigh* Chapter XYZ in my book explains the process :). Whenever you traverse over a site, its site manager becomes the active component registry. So if you haven't traversed over that site yet, the utilities in that site won't be found. It's that simple. So specifically, when I'm in the root of the ZMI, tick a CMF/Plone site and press Delete, will I be traversing over it or not? Of course not. Your URL doesn't reach as far as the CMF/Plone site. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: Delete trouble
Dieter Maurer wrote: Martin Aspeli wrote at 2007-3-25 12:46 +0100: ... I agree, except I think there could potentially be lots of places where this could be happening. In the general case, it's probably safe for that code to assume the utility is there, and treat it as an error if it's not, but during site deletion, it is probably at the mercy of the order of deletions. At least that's my guess. I would not find is a good approach, if exceptions were silently suppressed. Let's look at this closer: - There's probably an event subscriber for IObjectBeforeDeleteEvent on all Plone or CMF objects that makes sure that the deleted item is also purged from the unique ID tool. So far so good. - If that subscriber uses getUtility() calls and doesn't catch a ComponentLookupError, it bluntly assumes that all such content objects must live in an environment that has a unique ID utility. That's asking for a lot (it's almost as bad as simply wanting to be able to acquire portal_uuid or whatever it's called). - To make reuse easier, the suggested pattern is to check if such a utility can be found and then do the unregistering (or even registering when the object is added). If the utility can't be found, then that's too bad but shouldn't impact the actual use of the content type. After all, it's just a dumb content type. This isn't about silently suppressing exceptions, it's defensive programming to increase flexibility. If we know that during deletions exceptional cases could happen, we should inform the component lookup process that we are doing deletions such that it can be less strict in its behaviour. "Informing the component lookup process" is exactly the queryUtility() call that I meant. It returns None if the component can't be found. In combination for a check if the utility is None or not, this is the "less strict behaviour" that you're asking for. However, usually the "I am going to be deleted" event is signalled before the actual deletion takes place. Therefore, the event processing still should find all utilities around. Not if you haven't traversed into site. Then the local utilities won't be found. I suggest reading the chapter on Sites in my book. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: Delete trouble
On 27 Mar 2007, at 20:57 , Dieter Maurer wrote: As so often, we have completely different views on how things should be: When I have an "IObjectBeforeDeleteEvent" subscriber which should update the unique ID tool, then it can assume that there is indeed a unique ID tool. And if the assumption is wrong, an exception should result. What makes you think you can make that assumption? This is Zope 2 all over again, where things just have to be there. That won't help making things more flexible. We have this situation here: there should be (and is) a unique id tool but the local registrations have not been performed. Nope, we're just not operating in a place where we can get to the tool. It's standard acquisition semantics. An exception is better than silently omit the update of the existing unique id tool. You could argue that the local id tool does not need to be updated as the complete site (including the tool) gets deleted. Indeed. But would the effect be different, if I used: plone_site.some_folder.manage_deleteObjects(). Or in other words, is attribute lookup entailed in traversal? No. If it is not (which I assume), then your "defensive programming" would hide inconsistencies in the unique id tool -- similar to a "defensive try: except: pass". What kind of inconsistencies? We're deleting the thing anyway, what's the point to update it? ___ 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: getToolByName depreciation, getUtility, and five.lsm
Martin Aspeli wrote: We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. +1 The one thing I don't see here explicitly is the forward migration path. Make tools not depend on acquisition and you get can start looking them up using getUtility. This will take time, so I'd be ok if for now we can't use getUtility right away (unless you're willing to do manual __of__ing) I think it would be worthwhile to work towards a future where we have no tools or other programmer-support-mechanisms in content space. At least new stuff can be Zope 3-style already. I suspect that all context-less tools today could be rewritten to be regular global utilities, Absolutely. and all persitence-needing tools could be changed to be standard local utilities that if needed did getUtility(ISiteRoot) to get hold of the site root and acquire things from there (except, how does the site root then get an acquisition context? Maybe it doesn't need to?). Well, ideally we'll be able to model containment relationships using __parent__ in Zope 2 as well... However, if we still promote and use getToolByName() then people will not start using getUtility() and importing interfaces and we will find it more difficult to deprecate (eventually) and then move to a world where we can have real utilities (where possible/sensible). I can say from personal experience that deprecating less in more time is easier on the people and on yourself :). Going back to square one, the reason why we (and I'm very guilty in this) pushed for something at the framework level (spawning five.lsm) was that originally we ended up with calling code needing to do: >>> from Products.CMFCore.interfaces import IWorkflowTool >>> from zope.component import getUtility >>> wftool = getUtility(IWorkflowTool).__of__(context) Such explicit wrapping is black magic voodoo to most people and would probably lead to lots of hard-to-debug errors. (Welcome to Acquisition!) Requiring people to know *when* to wrap and when it's not necessary is tantamount to requiring them to know the implementation details of each tool. getToolByName sounds like a sensible abstraction, don't you think? We don't mean to belittle the hard work that anyone has put into this so far, and we hope this is received in the spirit that it is intended. We are willing to implement this if we can reach some consensus that this is the right thing to do. This is the part of the email I like the most :) It's a bit scary to have to revert the hundreds of changes that have been made to the Plone 3.0 codebase and probably hundreds more to the CMF codebase to move to getUtility, th
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: CMF Tests: 9 Failed, 2 Unknown
Maurits van Rees wrote: Maurits van Rees, on 2007-03-29: I see the same problem in a Plone Product of mine (eXtremeManagement) where bookings added after the DST get listed a day earlier in one page template. When I add a booking somewhere in November (I can choose the booking date) that one gets listed fine again. I am wondering what should be done. I *think* I can fix my own Python Script that is responsible for this now I know that DST is involved. I want to move to a browser view anyway. For the record: I just fixed it in my product. This is probably *very* specific to my product, but maybe it gives someone hints for the failing cmf tests. Here is the changeset: http://dev.plone.org/collective/changeset/39931/eXtremeManagement I was iterating through all days of the month, doing date+1 to go to the next day. That is apparently not the right thing to do in a DST context. I believe date+1 will simply add 24*60*60 seconds, hence the offset when adding over the DST switch. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: CMF Tests: 9 Failed, 2 Unknown
Sidnei da Silva wrote: On 3/29/07, Tres Seaver <[EMAIL PROTECTED]> wrote: The cheeseshop shows a pytz-2007d version: http://cheeseshop.python.org/pypi/pytz I was refering to the version included in Zope. That's because we're using a stupid vendor import instead of simply requiring it as an install (same with docutils, btw... at least with twisted we use an external). There are two pytz-related bugs in the Zope 3 bugtracker: - https://bugs.launchpad.net/zope3/+bug/98494 - https://bugs.launchpad.net/zope3/+bug/98495 which were both suspiciously filed on March 13th this year, therefore shortly after the new DST change date. The latter one is about updating pytz... When Zope 3 becomes eggs (we're almost there now), I really really hope we can simply depend on 3rd party packages as eggs... -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. I would only be comfortable doing that if we had unit tests for those tools that aren't acquisition-dependent. And by unit test, I mean real unit tests and not a ZopeTestCase. That's the only way we can really be sure that that a tool can function as a utility, an independent component, w/o acquisition. Not knowing the codebase, I suspect that this isn't the case and suggest using getToolByName for all right now and adding such tests to the TODO list for the next CMF release. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: [dev] unresolved site manager related issues
yuppie wrote: I'm judging by the solution itself *and* by the fact that we made a decision long ago and released a beta based on that decision. We should reverse that decision only if we are sure it was a mistake. I think it was a mistake. It's ok, we all make mistakes. It's good that we caught it before a final release. Why a mistake? Because some CMF tools were apparently not ready to be looked up as pure Zope 3 utilities yet. They depend on their acquisition context. That's something the Zope 3 CA (deliberately or not) simply doesn't give you. Kapil's also right when he says that utilities by principle are context-less components. the reason why a) was proposed is that the current usage isn't about adopting the zope3 api, its subverting its usage and meaning by introducing context dependencies where there were none before. a utility is context independent, the majority of cmf tools are not. I still don't buy that context argument. Utilities and tools both are used in the 'context' of a site. You just gave the definition of a tool, not the one of a utility. The only difference is how the knowledge about the site is used: Just for lookups or also for acquisition wrapping. If a tool needs to get to the site object in order to operate, it might not be such a good idea to convert it to a utility. It might make more sense as an adapter... What I'm saying is that the "all tools are utilities now" assumption might've been a bit too naive. On the other hand, there are valid use cases for accessing the site object. Acquisition is only one method here and it happens not to be supported by the Component Architecture. So it seems those tools aren't ready yet, though fortunately the evolution towards a different way of looking up the site object is simple; until then we also have a simple fix (undeprecating getToolByName). instead of introducing implicitness into the zope3 apis that imo defeats the purpose of using them in the first place, we should fix our tools so they can be used with the zope3 api and are not contentspace/context dependent, and till they are so continue to access them as we have been. a clear migration path that adheres to this principle was outline in a). I can see why you want to do it this way around, but I can't see why switching first to utility lookups and changing the implementation later is a mistake. I'm not aware of any problems that can't be resolved by improving the site managers / registries. At this point I don't either. All I know is that you're creating more and more code (and dependencies) just to get getUtility() calls working. Code, as you know, has the tendency to sit around forever. By introducing this Franken-ComponentArchitecture-with-Acquisition system, you'll not only increase the maintenance burden on your part, you'll also taint an API that has been pretty predictable and clear before. I would also bet that the existance of this hybrid will actually slow down the evolvement process, as there will be no apparent reason to refactor tools not to depend on acquisition anymore. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: [dev] unresolved site manager related issues
yuppie wrote: Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. setSite() is something that influences the place (= registry) that we look up the utilities from. It doesn't influence the "context" of the utility because tilities have no context. Sure, utilities might be local and even persistent. But that is a registration detail, not an implementation detail. The name "site" in Zope 3 is confusing. "Place with component registrations" is better. So, let's pretend setSite() was called updateCurrentComponentRegistryFromPlace(), it becomes pretty obvious that it has nothing to do with what the utility does. All it does is tell the Component Architecture which component registry to look up things. The fact that this registry happens to be associated with a place in the object hierarchy is completely irrelevant to the Component Architecture. We just don't pass that 'site context' explicitly to the component as in Zope 2. Right. The utility doesn't even *get* the context (and it shouldn't need it.) And in Zope 2 we don't pass the context in either. The tools get it by doing aq_parent(). This should be converted to a lookup, because it's not about the hierarchy that the tool happened to be placed in, it's about getting one very specific object: the CMF site. I still don't buy that context argument. Utilities and tools both are used in the 'context' of a site. You just gave the definition of a tool, not the one of a utility. By 'site context' I don't mean an Zope 2 acquisition context or an adapter context. I mean the site specific local environment that is usually looked up based on setSite or provided by CMF tools. Utilities shouldn't care which "site context" they've been registered at. If they want a specific object like the CMF site they should look it up. The only difference is how the knowledge about the site is used: Just for lookups or also for acquisition wrapping. If a tool needs to get to the site object in order to operate, it might not be such a good idea to convert it to a utility. It might make more sense as an adapter... What I'm saying is that the "all tools are utilities now" assumption might've been a bit too naive. Of course CMF tool interfaces have some methods we would not add to a new utility interface. But most of them would become views, and as long as we pass in the REQUEST explicitly they are still valid utility methods. I'm not aware of any tool methods that should be converted to site adapters. Most tools use the 'site context' just for the security machinery. The other reason why tools needed the context was looking up other tools, but that is obsolete in CMF 2.1 beta. I consider every other usage of the acquisition context a bug. Good. Then fix those "bugs" and we no longer need any acquisition wrapping of local utilities at all (and it should be ripped out of five.localsitemanager again). This would, of course, be an acceptable solution. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Moving to browser views
Charlie Clark wrote:
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that work
with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or should I
use an adapter? The templates are TAL and the only difference to an HTML
page is the different response header.
2) how do I pass in values derived specifically for these views? ie.
going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
to the appropriate call inside a browser view. I haven't been able to
work this out based on the examples or the Zope 3 book.
You know, I wrote a whole book for learning how to use this Zope 3
stuffm (and that includes explanations of how to use it in Zope 2 via Five).
--
http://worldcookery.com -- Professional Zope documentation and training
___
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: pdf generation
David Chelimsky wrote: I'm using zope 2.7.8 and looking for a means generating a PDF document. I've googled and looked around a bit but everything seems rather dated (stuff from 2002). That means this stuff is only marginally older than your Zope version ;). What are you all doing to deal with this these days? I've used http://www.reportlab.org with sucess. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: pdf generation
Charlie Clark wrote: Do you know of a Zope Product that already wraps report lab, or do you recommend just accessing directly with a script? I can't think of anything that would do this for you: transforming HTML to PDF doesn't usually work very well. Reportlab is fairly easy to use and extremely fast. Except that it's apparently not thread-safe and should therefore be handled with care. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: CMF collector on Launchpad?
Jens Vagelpohl wrote: Andreas Jung is in the process of getting the regular Zope 2 issue collector moved onto Launchpad. He said the Launchpad guys could move other collectors like the CMF collector at the same time. The question is, do we want this? My vote is "-0.5", mostly because I never used Launchpad. One drawback that was mentioned is the fact that bugtracker emails do not contain the full bug history. From other bugtracker experience I know that's very annoying. Andreas mentioned some arguments for the move, like having the same user base on all those collectors, the ability to move bugs between them, and a much better user interface than the sometimes odd collector UI. In general I'm +1. I agree about the full history in the email, though. Perhaps we can get it at some point if we bug the Launchpad people enough. As far as the user interface is concerned, I actually find the Launchpad one a bit cumbersome at times, too. It's much speedier than our CMFCollector on zope.org, though. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: Eggification redux
Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. We badly need it, not only for Zope 3 proper but also for projects which consume Zope 3 eggs (probably Zope 2 in the future, but naturally also grok). +1 to the eggification -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: [Zope-PAS] Re: Eggification redux
On 25 Sep 2007, at 13:20 , Jim Fulton wrote: On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote: Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. I don't know what you mean by this. There are several problems. * We've had to nail some of the versions because buildout was being a bit over-zealous when getting eggs on Windows. It would take the newest egg, despite the fact that other eggs had binary releases. I guess that's not its fault. But it's a working set problem. * When package A depends on Y and package B also depends on Y, but with some version restrictions, buidout will first try to get the newest version of Y when installing A. But then when installing B, it is likely that it has to get a different version of Y. The result is a version conflict. This could also easily be fixed with a working set that dictates which versions would be used from the beginning. * Even with newest=false enabled in grokproject's buildout.cfg template, the versions that people will end up when trying out grok are non-deterministic. This has led to people installing newer versions of something, sometimes even faulty releases, even though Grok hadn't been tested with these newer versions yet and older versions that were known to work were the better choice. Again, a working set problem. ___ 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] Known working sets II [was: Eggification redux]
(Also CCing zope3-dev where the first known working set discussion started a while ago) Tres Seaver wrote: This is the "known good" problem. I'm pretty convinced that adding some kind of "PyPI subset", where gardeners for a given "package set" keep the list of packages / versions known to work well together, is the only way out of this issue. E.g., a URL like: http://pypi.python.org/pypi/release/zope3.4 would be usable as an 'index-url' for setuptools: when used this way, setuptools would only find / install eggs from the "gardened" set, rather than whatever anyone happened to have uploaded that day. If PyPI can't be tweaked to provide such a feature, we may need to come up with some kind of mirroring scheme which does allow it. This is certainly an interesting approach. I'd be curious how you would garden this known working set. Martijn makes a pretty good case for maintaining such working sets close to the package in question (e.g. the grok egg, the Plone egg, etc.). I see two more solutions: * A versions.cfg that's loaded via HTTP. zc.buildout actually supports this now which makes it quite appealing. Also, far as I know, all major deployers of Zope3 that use zc.buildout for deployment use this form of pinning egg versions right now, which means it's actually being used out there. * Adding version conflict resolution to zc.buildout and/or setuptools. That way you could create meta eggs (e.g. the 'Zope' egg) with '==' version specificers (for Grok, the 'grok' egg would function as the meta egg as well). If this would cause version conflicts (and they often occur in buildout due to the lack of a full dependency tree before download), it should be possible to say which egg's versions are authoritative. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: [Zope-PAS] Re: Eggification redux
On 25 Sep 2007, at 14:06 , Jim Fulton wrote: There are several problems. * We've had to nail some of the versions because buildout was being a bit over-zealous when getting eggs on Windows. It would take the newest egg, despite the fact that other eggs had binary releases. I guess that's not its fault. But it's a working set problem. It's probably a setuptools problem. It would probably make sense to give buildout a switch to prefer binary releases where they are available. (Perhaps the new prefer-final option would help here.) Not when it has to chose between ZODB 3.8.0b2 and 3.9.0a1dev-r12345, of which are neither a final release. We really need to get to final releases. * When package A depends on Y and package B also depends on Y, but with some version restrictions, buidout will first try to get the newest version of Y when installing A. But then when installing B, it is likely that it has to get a different version of Y. The result is a version conflict. This could also easily be fixed with a working set that dictates which versions would be used from the beginning. IN the long run, this would be better served by a better algorithm for constructing setuptools working sets. ... which would require having access to the dependency data before installation. Nevertheless, we need something in the short run. BTW, since "working set" has a rather important meaning for setuptools, I'd rather we find a different term for what you are talking about. Oh, you're right. Tres has used the term "known good set" in the past, I believe. * Even with newest=false enabled in grokproject's buildout.cfg template, the versions that people will end up when trying out grok are non-deterministic. This has led to people installing newer versions of something, sometimes even faulty releases, even though Grok hadn't been tested with these newer versions yet and older versions that were known to work were the better choice. Again, a working set problem. Right, but I don't understand how having one of these things for Zope 3 would help. After all, a new package that is tested and added to the 3.4 release might still not work well with Grok. I see "known good sets" like the old tarball release, in the sense that we can say Grok 0.x works with Zope 3.y.z (for specific x, y, z). Likewise, I'd like to be able to say that Grok 0.x is known to work well with a particular known good set of Zope. Modifying the known good set (by adding a newer version of a package, or by adding a new package altogether) would constitute a new version of the known good set which we'd have to try Grok out with before we give it our blessing. If we apply our release semantics (major/minor/bugfix versions) to known working sets (I think we should), then we might also loosen the nails a bit and say that as long as you stay within the bugfix versions of one known good set, you're fine. We've done this for releases in the past, I don't see why we can't keep doing this. ___ 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: Move CMF collector to Launchpad (redux)
Charlie Clark wrote: Am 29.10.2007 um 21:17 schrieb Wichert Akkerman: It seems that the Launchpad database is not separated by product. I was just checking the bugs fixed in the latest relase of Zope and #2339 refers to something completely different related to Ubuntu. I would have expected bugs from unrelated projects to kept separate. The fact that they are not is useful: it allows you to move a bugreport from one product to another. For any migration the loss of the bug id is pretty major. The bug id won't be lost. Launchpad has a mapping between the old bug ids from the zope.org collector to the new launchpad ids. This works well for the Zope 2 and Zope 3 collectors already. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: eggification status?
yuppie wrote: Wichert Akkerman wrote: A related question is: how do we want to eggify CMF? It seems to make sense to create one egg for the whole of CMF and a second egg for GenericSetup. Why not one egg for each CMF product? Can you please elaborate? *Why* one egg for each product? We'll just end up with the same egg madness that we have with Zope 3 (e.g. zope.app could've just as well stayed one big egg, IMO). It's not like the different parts of the CMF need to move at separate speeds... ___ 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: Content types based on Python objects
Charlie Clark wrote: Am 28.11.2007 um 14:03 schrieb Charlie Clark: class Grid(dict, PortalContent) ... TypeError: Error when calling the metaclass bases multiple bases have instance lay-out conflict Looks like using the old favourite UserDict solve the incompatability problem. class Grid(UserDict, PortalContent): ... Right. You can't mix built-in types with ExtensionClasses (pretty much anything in Zope 2 is an ExtensionClass). Actually, subclassing the built-in types usually only works for trivial cases. UserDict (or PersistentDict) is the right thing to use here. ___ 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: Working with Zope 3 skin layers
Charlie Clark wrote: I've defined and configured a layer and it works when called by ++skin++ traversal but I have problems if I configured views to work with it explicitly: I get "not found" errors. ie. fails for /@@detail.html but Right. This will look up the 'detail.html' view for (context, request). Now it depends on what layers the request has applied to. Unless you've changed anything in the default skin configuration, it will have Zope's default skin. Since the 'detail.html' view above wasn't registered for the default layer but for soemthing else, it's not found. is fine with /++skin++charlie/@@detail.html Yup, because if you don't specificy a layer explicitly, will register a view for IDefaultBrowserLayer. Your charlie skin probably inherits from IDefaultBrowserLayer (either directly or indirectly). That's why this works. Of course, this ties in with what I get from Zope - that the adapter can't be found. I suspect I've misunderstood something fundamental on how views work with layers. My book has a large section devoted to this. :) Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily "switch off" those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. ___ 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: Working with Zope 3 skin layers
Charlie Clark wrote: What I think is still confusing me is: 1) I have created my dedicated skin 2) I have registered a view for that skin I assumed that by registering the view for the skin, the view would automatically use the right layer when called. Views don't "use" layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. The effect being much the same as a customised view in a CMF layer: higher up the chain takes precedence. Zope 3 layers and skins work exactly like that. But it seems that this is not the case: unless it is set otherwise Zope will use the default skin. Sure, but that's just like in the CMF where you tell the portal_skins tool which skin is the default. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in "Properties" page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily "switch off" those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found? Uh, it's an interface... how can it not be found? Or how do you "not include" ICMFDefaultSkin? Using overrides? By having your skin interface not inherit from ICMFDefaultSkin, just like in the CMF where you would remove the cmf_default layer from the skin definition if you didn't want to have the views from cmf_default available. PS: in your book the appendix to ZCML browser:defaultSkin says "see browser:skin". This has been deprecated, I think. Ah, thank you! ___ 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: Working with Zope 3 skin layers
Charlie Clark wrote: Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen: Views don't "use" layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-) Um, this is explained in detail in my book. Views are always looked up like this: getMultiAdapter( (context, request), name="foo.html" ) (whitespace added for clarification.) So by applying marker interfaces to the request, we can change the output of that adaption. See pages 168-169 in my book. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in "Properties" page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! That's what's so easy about them! :-O When does the skin name get used apart from in ++skin++ urls? Wherever you'd like to use it. Perhaps you'd like to show a list of available skins to the user so that s/he can choose one. Views are still registered to layers, ie. interfaces, aren't they? Yep. What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an "administration" layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different "skin". Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work. I'm not quite sure I'm following you here. Often skins mostly contain custom macros, meaning all views are registered for some default layer (e.g. IDefaultBrowserLayer) and they look up macros using context/@@standard_macros. Then it's up to the specific skin to provide a standard_macros view. This is the one that defines the look and feel of the site and therefore changes from skin to skin. This is exactly what my book explains and does (see Exapmles 10.3.2 and 30.3.3)! Forgive my bluntness, but it's hard to believe at this point you've read it... You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs. The IWorldcookerySkin interface doesn't inherit from Rotterdam. And to be honest, I wouldn't know what else to write. I even have a "Flashback" box that compares Zope 3 style layers to CMF layers and skins on page 173. And what I've written in the two previous emails were mostly rephrased passages from my book anyway. ___ 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: License file question
Maurits van Rees wrote: Raphael Ritz, on 2008-05-29: Not sure whether that's following best practice but here is how paster/zopeskel generate this at the moment (this is taken from a custom add-on I'm currently working on): [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs incf incf.applications.egg-info README.txt setup.cfg setup.py [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs HISTORY.txt INSTALL.txt LICENSE.GPL LICENSE.txt How do others handle this? I can understand putting the HISTORY in the toplevel docs/ directory of a package. Btw, the zope.org convention is CHANGES.txt. See [1]. But personally I like having it inside the "main" folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. That way when changing a file in the main directory and you want to change the history you do not need to descend three directories and go to docs/ to change that. One of the directories is largely superfluous: src. I think the only reason we have it is so that 'setup.py' isn't on the PYTHONPATH. Or something. And in bundles with svn externals the top level docs/ directory is not even visible because you only include the main folder. So you miss the history file (and the README.txt if you keep that in docs/ as well). I think a docs folder adds unnecessary structure in many cases. I remember that at least once I changed something in a plone package inside a bundle, Wichert asked me to update the history file and I ended up wrongly updating the history file of CMFPlone because I never even saw the real history file belonging to that package. :-) That's because bundles are stupid :) [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt ___ 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: License file question
On 29 May 2008, at 11:27 , Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: But personally I like having it inside the "main" folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. You probably want to use a MANIFEST.in anyway and that can easily be used to include everything in doc/ or other places. Good point! ___ 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: Add forms and menus
Daniel Nouri wrote: Martin Aspeli writes: Yuppie writes: but in general that's the way to go. Since z3c.form became the standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in the same direction. Unfortunately using plone.z3cform is no option for CMF because it has a different license and repository. *If* Plone wants to donate that code to the Zope Foundation or someone writes something similar (maybe five.z3cform), I'd be happy to help with CMF integration. Bah, I hate these discussions. I'm sure Daniel Nouri would be happy to relicense. Re-invention for the sake of a license is just too dumb. I'd prefer to keep the name to avoid breaking existing packages, though. Another option is to factor out a few things to a five.z3cform and have plone.z3cform import from it as appropriate. I just relicensed and moved plone.z3cform to the Zope repository: http://svn.zope.org/plone.z3cform/trunk/ Yay! Despite the "plone" namespace, it works fine in CMF and pure Zope 2. A namespace is just a name :). *Some* of the functionality (modules) is Plone or CMF specific. The default configure.zcml aims to be usable without Plone or CMF. There's a buildout.cfg in there that pulls Plone. I'd like to replace it with a Zope2-only one (and maybe move the existing buildout to another location). +100 The tests work without Plone. Awesome. By the way, I've collected a few conventions about maintaining software in svn.zope.org: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt It would be nice if everything in svn.zope.org would adhere to these conventions. I'm just mentioning this since there may be some differences to Plone's conventions. ___ 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] IMember: does it exist?
Paul Winkler wrote: > Rob Miller <[EMAIL PROTECTED]> writes: >> then CMF does it's normal wrapping of these user objects using the >> standard >> MemberData implementation. > > Hmm, right, so then this might still be on-topic here ;-) > Maybe the right thing is for CMF to do a directlyProvides() call in wrapUser? Please consider using alsoProvides() since directlyProvides *overrides* all directly set interfaces. alsoProvides *adds* to them. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
