Re: [Zope-dev] (optional) CSRF protection in zope.formlib
Hi Jan-Wij, +1 for implementing convenient CSRF. I wonder if you could make your implementation more orthogonal by implementing a CSRF field/widget, and make your `protected` attribute simply trigger the inclusion of this field implicitly. This way you wouldn't need to change the `*pageform.pt` templates like you do now, and `setupToken()`/`checkToken()` would move to the widget code. Cheers, Leo On Wed, Sep 18, 2013 at 11:41 AM, Jan-Wijbrand Kolman janwijbr...@gmail.com wrote: Hi, I've been working on CSRF protection for zope.formlib. I have a csrfprotection branch in my zope.formlib fork on github. The changes against the current zope.formlib mainline can be found here: https://github.com/**janwijbrand/zope.formlib/**compare/csrfprotectionhttps://github.com/janwijbrand/zope.formlib/compare/csrfprotection When creating form components based on zope.formlib.form.FormBase, one can enable this protection just by setting the attribute ``protected`` to True on the component. This implementation is based on the following assumptions: * We do not want to keep server-side state(!) * An attacker that attempts CSRF cannot get to information stored in cookies that are meant for the domain of the (forged) request. * The token stored in the cookie is sufficiently random and long, to be practically unguessable by the attacker. * The form submit is deemed valid as long as the token in the cookie is identical to a hidden input value that is part of the form submit. My questions: * Do you find this feature useful enough to be, in principle, included in zope.formlib? * I'd like to kindly request someone to review my branch and provide feedback. The included test cases describe a few more questions and concerns about this implementation. Thank you in advance! kind regards, jw __**_ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/**listinfo/zope-devhttps://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/**listinfo/zope-announcehttps://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/**listinfo/zopehttps://mail.zope.org/mailman/listinfo/zope) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] five.grok - svn
Thanks! On Thu, Apr 11, 2013 at 10:37 PM, Stephan Richter stephan.rich...@gmail.com wrote: On Wednesday, April 10, 2013 04:43:17 PM Leonardo Rochael Almeida wrote: Can anyone please migrate five.grok to GitHub? Done. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] five.grok - svn
Hi repository specialists, Can anyone please migrate five.grok to GitHub? Some people have fixes for it, but don't want to touch SVN ever again, like its some sort of plague... Thanks in advance! Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 3 support status page
Cool, looks nice! On Mon, Jan 28, 2013 at 3:27 PM, Marius Gedminas mar...@gedmin.as wrote: I wanted to have an up-to-date status page for the status of the Python 3 porting efforts of various zope-ish packages, so I made one: http://zope3.pov.lt/py3/ Source for the data extraction bits: https://github.com/mgedmin/ztk-py3-status Source for the presentation bits: use View Source in your browser. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Status of github migration
Hi Jens, On Thu, Jan 10, 2013 at 11:47 AM, Jens Vagelpohl j...@dataflake.org wrote: [...] All other repositories (Zope, Products.*) were test migrations where I asked for feedback and never got any. They are throw-away and not final. The only finished migrations are yours and Tres'. I've been overly busy with these last couple of monks with job change/country relocation/new year, so I couldn't review those migrations before. I took a quick look at the Zope migration now and I think it's excellent. The only thing I'd add is that I'd also migrate branches 2.12 and 2.13 branches since they're all active, even if just for bug/security fixes. Having those branches means that back/forward-porting fixes is easier. Although we could always recreate the branches based on the tags, which were also nicely migrated. I think you mentioned this before, but I couldn't find it in a quick archive search, but which script did you use for those migrations? Thanks for all the work! And thanks also for the very nice mirror at: git.zope.org Cheers, Leo jens ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime issues with negative offsets
Here's Guido's official explanation for the divmod behaviour: http://python-history.blogspot.com.br/2010/08/why-pythons-integer-division-floors.html IMHO we should treat negative offsets specially, doing the divmod() with -60 in that case. Regards, Leo On Fri, Dec 7, 2012 at 5:22 PM, Juan A. Diaz nue...@ravvit.net wrote: secconds / 60 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] AccessControl C extension, ExtensionBase, Cylic memory and tp_traverse
Hi Silvain, Thanks for the deep analysis. Did you put this code in a branch somewhere for us to take a look? Cheers, Leo On Tue, Nov 6, 2012 at 2:54 PM, Sylvain Viollon sylv...@infrae.com wrote: Hello, I recently find out I had a memory leak in Silva, with Python 2.7. After playing a while with various tools (objgraph is nice), I found out I leaked between two and three objects at every request: - an AccessControl.SecurityManagement.SecurityContext instance, - two bound methods to ZopeSecurityPolicy.validate and ZopeSecurityPolicy.checkPermission. Of course, those leaks disappears as soon as I use the Python implementation for the security instead of the one in C. And I have tested it as well with various older versions of AccessControl, and have the same behavior. Looking closely at the code, I see that those objects are used internally by the SecurityManager. The SecurityManager is implemented in C, using the facilities provided by ExtensionClass. The SecurityManager properly implement the method dealloc, and it is correctly called. However, since it holds objects managed by the Python garbage collector (namely one called context that is an instance of AccessControl.SecurityManagement.SecurityContext, one called policy, that is an instance of ZopeSecurityPolicy, and a two last ones that are the bound methods ZopeSecurityPolicy.validate and ZopeSecurityPolicy.checkPermission), it should implements the tp_traverse method, but it doesn't. This is not done because ExtensionClass uses the slot for tp_traverse to store something else (namely what goes in tp_methods later). In a local checkout of AccessControl, I converted the SecurityManager C code not to rely on ExtensionClass anymore, but use the 'new object' C API, that is mostly equivalent to ExtensionClass, and implemented the tp_traverse method. This fixed my memory leak. I propose you to commit my code in a branch, and after review to merge it with the branch 2.13 and the trunk of AccessControl. I don't see any argument against not using ExtensionClass anymore for SecurityManager, and it might be possible to convert some other classes to the 'new object' C API too. I can have a look at it. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] libmysqlclient_r.so.15: cannot open shared object file: No such file or directory
Hi, This is the mailing list to discuss development of Zope itself. It's not strictly a support mailing list. You should likely contact: https://mail.zope.org/mailman/listinfo/zope In any case, by googling [libmysqlclient_r.so.15 centos 6] I found this page: http://forum.teamspeak.com/showthread.php/63894-libmysqlclient-so-15-not-found Which explains how to install the MySQL-shared-compat package which likely contains the library you need. In any case, you don't describe what you actually did to migrate zope from CentOS 5 to 6, but it looks like you simply copied a number of files from one machine to another. You should recompile your MySQL-Python bindings for a newer version of MySQL. Regards, Leo On Mon, Oct 29, 2012 at 9:40 AM, Babylakshmi Muthusamy babylaks...@ibioinformatics.org wrote: Hi, I have migrated zope from Cent OS 5 to 6. Now I am getting the following error when I try to save or run external method using mysql: Error Type: ImportError Error Value: libmysqlclient_r.so.15: cannot open shared object file: No such file or directory Any help to fix this is highly appreciated. Thanks, Babylakshmi -- Babylakshmi Muthusamy Ph.D. student Institute of Bioinformatics 7th Floor, Discoverer Building International Technology Park Bangalore - 560 066 India Ph: +91-80-28416140 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/branches/2.12/ LP #1047318: Tighten import restrictions for restricted code.
On Mon, Sep 10, 2012 at 8:09 AM, Hanno Schlichting ha...@hannosch.eu wrote: On Mon, Sep 10, 2012 at 10:31 AM, yuppie y.2...@wcm-solutions.de wrote: CMF uses some ZTUtils in restricted code: Batch, LazyFilter, make_query and SimpleTreeMaker. The new Zope 2 releases (2.12.24 and 2.13.17) are not compatible with existing CMF releases. Is this intended? This wasn't intended. I agree these should have not been restricted. CMF could declare the ZTUtils it uses as public. But that would require new CMF releases for the new maintenance releases of Zope. And other packages might have the same problem. ZTUtils is part of Zope2 and clearly intended for use inside templates / restricted code. So it should be fixed there. Were the restrictions tightened too much in Zope? I'm not sure. There isn't really any clear documentation on what APIs you are supposed to use. It seems ZTUtils.__init__ sets __allow_access_to_unprotected_subobjects__ = 1 on the module scope level. But it doesn't use the allow_module or ModuleSecurityInfo APIs. I'm guessing this is all historical baggage and the proper APIs were only created much later. Maybe some other long term developers can chime in with their perspective? Without digging much in the history, I'm inclined to agree with this analysis. I think the new APIs should be used, and tests added, to make sure these ZTUtils utilities are available from restricted code. Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] (no subject)
Zope4 Lille Sprint 2012 Report The first thing we did was discuss the state of contributions to the Zope codebase, specially in light of many vocal members of the community that would like to use GitHub (and other members, less numerous but equally vocal, who would not like to use GitHub at all, but still want to use Git). Jens started investigating the options and will report to the Foundation board. Then we started reviewing the current state of various existing branches that try to advance the state of Zope trunk. Laurence rebased some previously existing parent pointers work onto the current Zope trunk, and Leonardo worked on restoring a minimal Welcome page on a just installed Zope instance that would not involve adding more persistent objects. We then took stock of what work is already done or is sufficiently advanced that we could reasonably expect to be ready soon: - WSGI as the only publisher, moving transaction handling back into it (i.e. a pure Zope4 wsgi app without any other middleware should be complete). This will likely be folded back into Zope 2.13. - Parent pointers - need to specify a minimum migration strategy, which should not require modifying all objects in your instance (mostly for objects looked up by C.A.: local site manager, utilities...) - Lots of stuff removed already - Decide on egg name (Zope2 currently, ideally it should be Zope) - ZMI tidy up (not removal, for this release). - WebOb based request - Remove Session and TemporaryFolder. Nice to have (i.e. if we have manpower to develop): - Use Chameleon and drop old ZPT implementation, but only if Plone has shipped with it by then (to be sure incompatibilities are fixed.) - Don't use docstrings to control publishing. The expectation is to be able to release a Zope4 alpha by the end of the year. Next sprint will be at the Plone Conference in Arnhem, focussing on WSGI and merging branches. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4 Sprint Report [was: (no subject)]
Sorry for the missing subject. Hit Send too fast. On Mon, Sep 10, 2012 at 4:51 PM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Zope4 Lille Sprint 2012 Report The first thing we did was discuss the state of contributions to the Zope codebase, specially in light of many vocal members of the community that would like to use GitHub (and other members, less numerous but equally vocal, who would not like to use GitHub at all, but still want to use Git). Jens started investigating the options and will report to the Foundation board. Then we started reviewing the current state of various existing branches that try to advance the state of Zope trunk. Laurence rebased some previously existing parent pointers work onto the current Zope trunk, and Leonardo worked on restoring a minimal Welcome page on a just installed Zope instance that would not involve adding more persistent objects. We then took stock of what work is already done or is sufficiently advanced that we could reasonably expect to be ready soon: - WSGI as the only publisher, moving transaction handling back into it (i.e. a pure Zope4 wsgi app without any other middleware should be complete). This will likely be folded back into Zope 2.13. - Parent pointers - need to specify a minimum migration strategy, which should not require modifying all objects in your instance (mostly for objects looked up by C.A.: local site manager, utilities...) - Lots of stuff removed already - Decide on egg name (Zope2 currently, ideally it should be Zope) - ZMI tidy up (not removal, for this release). - WebOb based request - Remove Session and TemporaryFolder. Nice to have (i.e. if we have manpower to develop): - Use Chameleon and drop old ZPT implementation, but only if Plone has shipped with it by then (to be sure incompatibilities are fixed.) - Don't use docstrings to control publishing. The expectation is to be able to release a Zope4 alpha by the end of the year. Next sprint will be at the Plone Conference in Arnhem, focussing on WSGI and merging branches. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
Hi, On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro rege...@gmail.com wrote: On Mon, Aug 20, 2012 at 10:28 AM, j...@nexedi.com wrote: This approach protects from: - legal risks posed by github Such as? I'll let Jean-Paul elaborate, but I suppose it could be something along the lines of GitHub suddenly disappearing with (some of) your content (code, forum posts, metadata like group associations) or making some other unwanted use of it, and you having no legal recourse because of some small print in some EULA somewhere that someone didn't bother to fully read. - instabilities due to ever changing fashion in code hosting (sourceforce then google code then bitbucket then github then etc.) Sure. At the cost of a lot of extra complexity, that is. - destruction, traceability or security issues posed by cloud infrastructure not controlled by ZF (logs, bugs, forums, not only code) What would these be. c.f.: https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation The point is not that these can't happen to ZF repos, but that ZF would have no recourse to fix the issue except to wait on GitHub to act on it. This approach enforces: - freedom for fashion victims to follow latest fashions Making it easy to contribute is not a fashion but a fundamental part of how good open source works. Yes, and both you and I are around long enough to remember when SourceForge w/ SVN was the easiest way to get others to contribute, which is why Plone originally selected it. Now it's GitHub and git. By fashion JP doesn't meant to say that the selection was frivolous, but that the same criteria can lead to selection of different tools/services at different points in time. In any case, this discussion seems to be converging, which is excellent. It is also one of those discussions that could be solved in less than an hour by folks talking over beverage, but takes a ton of attention bandwidth and time when discussed over e-mail. So I'd like to reinforce Vincent Pelletier's invitation to the Zope4 sprint that is going to be hosted in Lille next week[1] for which both Jens Vagelpohl and Laurence Rowe have confirmed their presence. [1] http://www.erp5.org/Zope4Sprint2012 I'm sure we can hash out a solution that works for everybody in a very short amount of time. Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: drop interactive feature of zdaemon
Speaking of handling command line options and eventually having (or not) an interactive interpreter, I'd like to point out Michele Simionato's plac. http://plac.googlecode.com/hg/doc/plac.html Just to throught it out there... On Tue, Jun 5, 2012 at 4:06 PM, Fred Drake f...@fdrake.net wrote: On Tue, Jun 5, 2012 at 10:00 AM, Jim Fulton j...@zope.com wrote: I (and many people I know) find the interactive feature of zdaemon annoying. I'd like to drop it, both to reduce annoyance and to reduce the amount of code to maintain. I've never found this a useful feature. +1 -- Fred L. Drake, Jr. fred at fdrake.net A storm broke loose in my mind. --Albert Einstein ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.file/branches/ulif-fix-menus/ Do menu-related configuration only if z.a.zcmlfiles is available.
+1 for merging On Mon, May 28, 2012 at 11:16 AM, Uli Fouquet u...@gnufix.de wrote: On Sun, 27 May 2012 21:09:44 -0400 Tres Seaver wrote: On 05/27/2012 07:36 PM, Ulrich Fouquet wrote: Log message for revision 126504: Do menu-related configuration only if z.a.zcmlfiles is available. Changed: U zope.file/branches/ulif-fix-menus/CHANGES.txt U zope.file/branches/ulif-fix-menus/src/zope/file/browser.zcml Hmmm, looks like you forgot to 'svn add src/zope/file/menu.zcml'. I was convinced I did, but apparently I didn't. It's in now. Thanks for the hint! The branch (ulif-fix-menus) could be reviewed now, although there is not much to review. I didn't manage to create a reasonable regression test for the use case, as it seems to be very difficult and complex to remove some installed package and make it temporarily unimportable. If someone has an idea how to do this with not too much effort, I'd be glad to add it. Simply changing sys.modules and sys.path seems not to be enough. If this test would be not crucial, I'd leave it this way and prepare a minor release, maybe with some additional changes (the buildout.cfg is a bit outdated and test coverage could be improved otherwise). Best regards, -- Uli ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Remove zmi_views menus from zope.file?
Hi Uli, Thanks for taking care of this. IMHO: Move to a conditional include of a menu.zcml that (or include a menu.zcml file that conditionally) registers the browser menus for zmi_views and release a new minor version, declaring an extra dependency on the packages that provides zmi_views. With this, release a new minor version that will be backward compatible, due to the conditional. Then release a new major version that removes the include and the conditional. Add to README the instructions for manually including menu.zcml if this functionality is needed. If you get tired, do just one of the above :-) Regards, Leo On Sun, May 27, 2012 at 3:52 PM, Uli Fouquet u...@gnufix.de wrote: Hi there, zope.file still registers browser menus for `zmi_views` in its browser.zcml. This is a problem if you don't have/want the ZMI but want to use zope.file otherwise (IMHO it also means an undeclared dependency, as none of the packages zope.file declares to depend on really provides this browser menu AFAICS). I see that it is easy to register such a menu yourself but it annoys and confuses people new to Grok/Zope. I'd therefore like to remove these registrations from zope.file, make it at least conditional, or move it to some `menu.zcml` or similar, not included automatically by z3c.autoinclude and friends. Is there a reason why that shouldn't happen? If not: what way would be the best in your opinion (removal/conditional/menu.zcml)? Best regards, -- Uli ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Remove zmi_views menus from zope.file?
Hi Uli, Not sure if you wanted to remove zope-dev from copy on purpose, but what we talk about below is probably of general interest... On Sun, May 27, 2012 at 4:38 PM, Uli Fouquet u...@gnufix.de wrote: Hi Leo, nice to hear from you, I hope you are well :-) I'm fine, thanks for asking! :-) Hope you're doing fine as well... On Sun, 27 May 2012 16:16:43 +0200 Leonardo Rochael Almeida wrote: IMHO: Move to a conditional include of a menu.zcml that (or include a menu.zcml file that conditionally) registers the browser menus for zmi_views and release a new minor version, declaring an extra dependency on the packages that provides zmi_views. With this, release a new minor version that will be backward compatible, due to the conditional. Then release a new major version that removes the include and the conditional. Add to README the instructions for manually including menu.zcml if this functionality is needed. If you get tired, do just one of the above :-) Yep, I planned in the same direction. The problem, however, is the condition. The 'condition:zcml' directive, AFAICS, only asks for existence of packages or features. But in the zope.file (or zmi_views) case I'd have to ask for zope.app.menus.zmi_views (which wouldn't be a package nor a feature). Furthermore if one asks for a package as condition, that could be wrong as people could define a zmi_views menu elsewhere and then the registrations should be included (okay, on the other hand one could tell them to include the menus.zcml manually then). I guess we could argue that whoever provides the zmi_views menu should provide a respective feature. Oh, and I haven't found out yet, which package exactly normally provides the zmi_views menu. Do you know it by any chance? I tried to locate it as well, but failed. What I could discover is that whichever distribution provides this will likely include a menu id=zmi_views ... directive somewhere. Since you mentioned on the grok list that previous versions of grok could work with zope.file, then perhaps you can search the eggs/ directory for this directive. Good hunting, and please keep us informed. Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding broken/missing support to zope.interface? (was: experimental.broken - Graceful handling of broken interfaces and components in the ZODB)
Not ZCA/ZODB maintainer, but a big +1 from me. I've also experienced the negative effects of missing code for (marker) interfaces in persistent data. Cheers, Leo On Sun, Apr 8, 2012 at 22:04, Ross Patterson m...@rpatterson.net wrote: experimental.broken is working well for me. It greatly aided me in getting through a particularly nasty upgrade allowing me to cleanup the ZCA cruft left by poorly behaved add-ons. I'd like to proceed with adding the core of this to zope.interface and I need the developers/maintainers to weigh in. The first and most fundamental matter is changing interface pickles such that they can be unpickled into something that can fulfill the minimum interface contract and don't break the ZCA. To that end, I'd like to add the following to zope.interface.interface: ... try: from ZODB.broken import find_global from ZODB.broken import IBroken def find_interface(modulename, globalname, Broken=IBroken, type=InterfaceClass): Find a global interface, returning a broken interface if it can't be found. return find_global(modulename, globalname, Broken=IBroken, type=InterfaceClass) except ImportError: IBroken = Interface def find_interface(modulename, globalname, Broken=IBroken, type=InterfaceClass): Find a global interface, raising ImportError if it can't be found. # From pickle.Unpickler.find_class __import__(module) mod = sys.modules[module] klass = getattr(mod, name) return klass ... class InterfaceClass(Element, InterfaceBase, Specification): ... def __reduce__(self): if self is IBroken: return self.__name__ return (find_interface, (modulename, globalname)) ... With this change, previously existing interface pickles will be different from newly committed ones but both pickles would unpickle to the same object. Also, running zodbupdate would convert all pickles to the new format. Is this the correct approach? If not, how should it be changed or what might be the correct way? Is there a better way to put the broken object support in ZODB and still have the same interface pickles when using ZODB? This still leaves the problem of instance provides declarations and component registrations which contain previously existing interface pickles for missing interfaces. Without addressing these, previously existing instance pickles cannot be unpickled and all component registry operations fail. experimental.broken addresses these by adding handling for broken interfaces when provides declaration are unpickled (in the ProvidesClass.__init__ method) and when component registries are unpickled (in the __setstate__ method of persistentregistry.PersistentAdapterRegistry and persistentregistry.PersistentComponents). Again, with these patches, missing interfaces don't break instances or registries and allow running zodbupdate to fix all existing pickles. Where should this support live? Should I keep it in a separate package, maybe just rename experimental.broken to z3c.broken or somesuch? Should it be merged into zope.interface and zope.component? Will the developers/maintainers of zope.interface, zope.component and/or ZODB please weigh in on this and give me feedback towards getting this finished? Thanks! Ross Ross Patterson m...@rpatterson.net writes: I've done some more work on this and I've gotten the component registrations fully working now with one exception that I'm having real trouble with. I'd like some help with that, more below. I'm also a bit more clear on what might be appropriate to bring back into zope.interface and I'd like feedback on that. Currently interfaces are pickled as globals. Given their centrality in any ZCA application, I think they should be pickled using a function: def __reduce__(self): return (find_interface, (modulename, globalname)) where find_interface, if ZODB.broken.find_global can be imported, in turn calls: ZODB.broken.find_global(modulename, globalname, Broken=IBroken, type=InterfaceClass) since find_global already has nicely abstracted graceful missing global handling. If this were added to zope.interface, and changed ZODB objects with marker interfaces or persistent registries where all the code for the interfaces is still available will then be updated with pickles that will gracefully handle missing interfaces in the future. Thus you could use zodbupdate to make sure that the interfaces in your ZODB will fail gracefully in the future. Do you agree/disagree that this belongs in zope.interface? What this will not address are existing interfaces-as-globals pickles where the original
[Zope-dev] PyConUS sprint on Zope 4
Hi, Anyone going to this PyConUS who would like to sprint on Zope4? Topics of particular interest to me include security (as I explained in a previous e-mail) and the new ZMI. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4 publisher/traversal, sprint topic
Hi, Sorry for the cross-post, but I'd like to talk about a possible sprint topic for the next DZUG sprint[1], and invite myself to it :-) After the last two rather serious security issues that were recently patched in the Zope2 code base, it is increasingly clear to me that, differently than what Hanno reported some time ago, it's not so much the ZMI that represents a huge security liability in the Zope codebase, but it's actually the way the current publisher happily traverses any attribute and publishes any method with docstring by default. The ZMI, of course, has its problems (ugly in appearance and even uglier in code), and I agree with Hanno on most everything he has to say about it, but I'd like to propose we start, for Zope 4, by tackling the potential security liability that is the Zope publisher itself, and the fact that it makes it easy to open up large security holes if you're not paying attention. I'd like to propose that publishing traversal in Zope 4 would, by default only traverse based on __getitem__ (not attribute lookup). For a minimum of backward compatibility, it could perhaps do a single traversal on getattr, and only after it has exhausted __getitem__ traversal. After this, if the traversal found something, it would only be published if there is an explicit indication of intention that the object in question is supposed to be published. Otherwise, raise a NotFound, as if the traversal had failed. One example of an explicit demonstration of intent is, for example, if it provides an IPublishable interface (I just made that up, other names can be considered). Taking a suggestion from Shane, we could have convenient decorators for people who wants to explicitly publish class methods. They could dynamically create ZTK views with the same name as the function that they wrap and allow (or perhaps enable by default) some form of CSRF protection. To ease code migration, we could consider that the InitializeClass call provides the same effect as the above decorator. This would allow large amounts of previously existing code to work without recoding, while at the same time avoiding the security trap of forgetting to call InitializeClass and thus exposing unintented methods. It could even remove the need for the single getattr traversal compatibility above. On top of that, if InitializeClass register these views to a specific ZTK skin, it would make it possible to disable them by default, unless that specific skin is in effect, which would alleviate what Hanno described as running phpMyAdmin accessible to the world with the same credentials and on the same domain as the rest of your application. Anyway, I think the above is on-topic for the next DZUG sprint and I'd like to work on it there. So, even if the sprint is supposed to be in German, and I don't speak a word of it, can I attend? [1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi , translation at: http://translate.google.com/translate?hl=ensl=autotl=enu=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Conversion old.zope.org to static site
Hi, Congratulations on this move, must have been a nice technical challenge. And although I wholeheartedly agree with it, there is a part of me that is sad to know that the old zope.org Zope insance has been shut down for good. Leo On Fri, Oct 14, 2011 at 11:35, Jens Vagelpohl j...@dataflake.org wrote: Hi all, Just as a heads-up: Jim Fulton and I have converted old.zope.org to a static website. This allows ZC to decommission the hardware and reduces the maintenance burden for everyone involved. We have tried to keep all URLs intact and the site navigation working at the same time, which required a little creative thinking. Some of you rely on resources from the old.zope.org site, such as release tarballs of older Zope versions and other products. Please test and ensure the files you need are still where you expect them. If you have problems, just contact me off-list and I'll take a look. jens ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] disabling zope.schema constraint check in edit form
Hi Joshua, On Thu, Aug 18, 2011 at 09:59, Joshua Immanuel j...@hipro.co.in wrote: [...] Worse case scenario is where I have a cancel action button which just redirects to another page, that too screams for the NameAlreadyExists error. For the 'cancel button' case, you need to have a form action with a validator that always validates, no matter what. You can find an example of one such null_validator here: https://svn.plone.org/svn/plone/plone.app.form/tags/2.0.3/plone/app/form/validators.py To use it, you do something like class MyForm(...): @form.action(..., validator=null_validator): def handle_cancel(self, ...) [... do the redirect ...] Cheers, Leo [...] ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pluggable template engine
Hi Malthe, How often is the adaptation called? For example, suppose a Page Template had a tal:repeat that rendered a macro inside of it. If that tal:repeat looped 5 times, do we get 5 more adaptation calls, besides the call of the outermost Page Template? Just asking out of curiosity, I haven't looked at the code, other than the interface link you posted. Cheers, Leo On Wed, Jul 20, 2011 at 17:24, Malthe Borch mbo...@gmail.com wrote: I've refactored the ``pagetemplate`` module to realistically support plugging in an alternative implementation of the parser and interpreter. http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/ Two new interfaces are added which serve as the plugging point see ``IPageTemplateEngine`` and ``IPageTemplateProgram`` in this module: http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/src/zope/pagetemplate/interfaces.py?rev=122300view=markup I'd like to propose merging this into trunk. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Hi Hanno, On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com wrote: I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with native interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal: I think what's going to stay is AccessControl, OFS (a bit lighter), ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of Zope Toolkit libraries like components, events, browser pages and so on. That's the kind of scope that should be possible to port to Python 3 and actually modernize enough to be understandable.(...) Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base? If we still have that minimalistic ZMI, all players in our community can decide how much effort they want to spend maintaining which legacy pieces technology, depending on what makes economic sense to them, without causing extra maintenance burden on the other players. [...] Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Hi Hanno, From the point of view of the ERP5 codebase, this direction for Zope2 should be mostly ok, save for a few comments below: On Sun, Jul 3, 2011 at 03:41, Hanno Schlichting ha...@hannosch.eu wrote: On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: [...] I think moving to Zope 2.12 and 2.13 does have some value for Nexedi or other large existing codebases, as you get support for current versions of the ZODB, Zope Toolkit packages and support for Python 2.7 with Zope 2.13. Since Python 2.7 is a long-term maintenance release for Python itself, this should provide a stable and good basis for the next years - the statements from the Python community aren't completely clear - but I'd expect to see ongoing maintenance until 2013 or maybe even 2015. Yes, these were the reasons we ported to Zope 2.12 to begin with. Going forward I can see two paths for Zope 2. Either we don't touch it at all anymore and let it bitrot or we try to move it forward and adept it to current best practices of development. Since complete rewrites almost always fail, like we have seen with Zope 3 - I prefer changing Zope 2. Agreed. If you are interested in stability I think sticking with an older version of Zope 2 is a completely sane and good approach. What me and others from the Plone community are trying to do with the Zope 2 codebase is to actually move it forward. We can either do that as part of the official Zope 2 release series or fork the codebase. Since so far there isn't really anyone else interested in working on the Zope 2 codebase, we keep changing Zope 2 without forking it. With the direction the Zope2 codebase has taken so far, I don't see any reason to fork it even if all current players keep depending on it. But can you explain to us a little of how you expect Zope2 to behave with the changes you're doing? There's a number of things I want to do. Not sure when I'll or others will have the time, but these are things I expect to happen in the next months or releases: - Continue to remove functionality tailored for TTW development, like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI - Document and use the WSGI publisher and remove obsoleted functionality like the virtual host monster, error_log, ZServer/medusa, zopectl/zdaemon In ERP5, we've made TTW development sane and safe, and integrated with VCSs (both SVN and Git), so the above paragraph sounds a little bit scary, though in reality it doesn't have to be. SiteRoot, AccessRules, HelpSys, of course, are really unused, so I don't fear their disappearance. As for the rest, most of the things that have been removed from core were done in such a way that they can still be used with Zope2, so ERP5 can happily keep using them. If things can keep evolving with this care we should be ok. As others have pointed out, the core url rewriting functionality of VHM is useful even in a WSGI context, and I'd argue that it should actually be made part of the root Application, so that we don't need a persistent object just for this. On the other hand, if we could get the ZTK version of this working (the one that used /++vh-host and /++vh-root url segments) I think it should be ok, and we could get rid of VHM completely. - Make the browser id manager, session data manager, temporary storage optional and remove it and request.SESSION from the core, instead we can use something based on Products.BeakerSessionDataManager / collective.beaker if someone has a need for sessions - Start using and storing parent pointers and remove Acquisition.Implicit from the most common base classes (a branch for this already exists with almost all core tests passing) ERP5 will probably get rid of all its uses of acquisition too at some point. We've recently taken a large step in this direction, but again, it can still be used as an add-on, so this is not a problem. - Merge five.pt (Chameleon) into the core and use it instead of the zope.tal/zope.tales implementation (which means no more RestrictedPython for templates). A few months ago, I and Malthe did some work to make sure that TTW ZPTs worked with five.pt. Malthe even surprised me with something that I thought couldn't possibly work and managed to get the RestrictedPython evaluator to translate python expressions in TTW ZPTs. So, getting rid of RestrictedPython is not strictly necessary for using five.pt in Zope2 core. Then again, we might decide to get rid of it for other reasons... Anyway, as long as there are still TTW addable ZPTs, PythonScripts and ZSQLMethods, ERP5 can still work. - Once most of the ZMI is gone, it should be feasible to drop DTML or rewrite what little is left as page templates If DTML is still available as an optional product/package, this should not be a problem for us, but we'll likely depend on ZSQLMethods (hence, on DTML) for a long time, since our ZSQLCatalog functionality is built heavily around
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ Removed the last remaining code to support `SOFTWARE_HOME` and `ZOPE_HOME`.
Hi Hanno,
I haven't checked deeply, but the change below seems to break
Products.ZSQLMethods. At least there is an import in
Products.ZSQLMethod from this location. And we depend heavily on it...
Since you're already around that piece of code, would you mind moving
it over there and releasing a new version of Products.ZSQLMetods? I
would be most thankful.
Cheers,
Leo
On Sun, Jul 3, 2011 at 17:19, Hanno Schlichting hanno...@hannosch.eu wrote:
Log message for revision 122084:
Removed the last remaining code to support `SOFTWARE_HOME` and `ZOPE_HOME`.
Changed:
[...]
U Zope/trunk/src/App/Extensions.py
[...]
-
-class NoBrains:
- pass
-
-
-def getBrain(module, class_name, reload=0, modules=None):
- Check/load a class from an extension.
-
- if not module and not class_name:
- return NoBrains
-
- if modules is None:
- c=getObject(module, class_name, reload)
- else:
- c=getObject(module, class_name, reload, modules=modules)
-
- if getattr(c, '__bases__', None) is None:
- raise ValueError('%s, is not a class' % class_name)
-
- return c
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Getting translation of python code string to work
Hi Morten, OK. Well I have this function now: def _(msgid, request): language = request['LANGUAGE'] return translate(msgid, domain='SimpleChat', target_language=language) Which sends all the relevant bits to the translate function. But, this doesn't work either, and I can see it is because the interpolate function call is used in translate. It seems you misunderstood my explanation (or I misunderstood yours), but are you trying to use your custom _() function instead of using a MessageFactory? the translation() function should be used WITH the results of calling MessageFactory() objects, not INSTEAD of them. First you create MessageFactory() objects in your code when creating messages, preferably as early and as little as possible. THEN, you call translate() on them, as late as possible, and as close as possible to the time where the translation is to be transmitted to the user. So do I need to setup some utility? In theory, IMessageDomain utilities need to be registered, but if translations are working inside Page Templates, then this is already the case. These utilities need to be configured before the translate() call happens (for example, when it is called implicitly during ZPT rendering), but don't need to be configured yet when calling _(some message) (assuming the _ object is a MessageFactory instance). I hope I'm not making this even more of a mess for you to understand... Cheers, Leo On Wed, Jun 1, 2011 at 09:02, li...@nidelven-it.no wrote: [...] On Tue, May 31, 2011 at 13:19, li...@nidelven-it.no wrote: Hi, I have a oldschool style Zope 2 product, which has an i18n directory containing translations. Using i18n:domain=SimpleChat in this product works fine in the page templates, Well, ZPTs generate message objects automatically from translated content, but they also explicitly translate all the message objects they get during interpolation between the literal parts of the template and the dynamically generated ones. but when I start translating text in a Python module using _(Translate me) I just get English text (instead of Norwegian, which is what I want). When you say I just get English text, what does exactly get mean in terms of code? Mind you, if you simple call unicode(message) you'll most likely only get the English version back. Same thing if you do: usome other string: %s % message To get an actual translation, you need to call zope.i18n.translate(message), eventually passing the target_languate=... parameter. Take a look at the zope.i18n module for details, specifically the translate() and negotiate() functions. OK. Well I have this function now: def _(msgid, request): language = request['LANGUAGE'] return translate(msgid, domain='SimpleChat', target_language=language) Which sends all the relevant bits to the translate function. But, this doesn't work either, and I can see it is because the interpolate function call is used in translate. So do I need to setup some utility? -Morten ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)
Hi Andreas, On Tue, May 10, 2011 at 06:55, Andreas Jung li...@zopyx.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am happy to announce that we have made progress with the zope.org relaunch project. The first public version of the new site is now available under http://beta.zope.org Very nice work. I would just like to give a small suggestion, which is to have 301 HTTP redirects from some non conflicting URL spaces on www.zope.org to old.zope.org, so that we don't lose search engine indexing and ranking of the old pages. Ex: the members area: www.zope.org/Members/itamar/CorruptedZODB - old.zope.org/Members/itamar/CorruptedZODB This should be very easy to achieve with a small number of Redirect Apache directives specifying permanent redirections. Cheers, Leo The basic idea behind the project is: - a minimalistic www.zope.org site giving a short overview about what Zope is - including all related app servers, CMSes, frameworks etc. which links to the related project sites (micro-site approach) - no more member contents on www.zope.org - the current www.zope.org will be stripped down to the current member contents and stuff that has to be preserved. www.zope.org will be renamed to old.zope.org later Constructive criticism and feedback is welcome _now_. I hope that we can fix the outstanding issues and integrate further feedback over the next few week in order to roll out the new site in the first half of June (2011 of course). Many thanks to my team (doing the real work): - - Michael Haubenwaller - - Kai Mertens - - Johannes Raggam Andreas Jung Zope Foundation -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJNyMVOAAoJEADcfz7u4AZjTgoLvigFQqPKlnn9J97+wrQRJkdr 8ErOiV6LCmpQeNLGDVodq0Y4JGnfQELu0ByzRz+xdig3NDAY9WyKTcxjJqu7DJ4H NnZ49dK47uvZaYbfq0kKjzIw9/FX092t5+lyVdiYst1d3JGEphz1iDsl+rySu4m1 xf3Zq5/+HH0xl2NPQ391dqPuoka+93ydygBfqR7TbBxr4t1GcbFs6vMhN5/13I7c g/Q6CWCKlBOfdSnof+p1M/EHtLelst7LPHXluB5tLSQcbpbhd3vtV2x19+InNBWs 3vbaWz9EFPQVdgrAc8f3Npw6+t1tn2JMBlLEJtwLmaErqjgDA4MMEmOmJPqNDqYo 7fyVWy0+OFeJdrGtO6MOZvmkgTxp+DBYjCOqzhzBijoHGaBQz1RsfH8IrWqhI+Av PRihsjM6ZBEhVcHyW/FIQfSvsYJCsim+xxcfkmUhUjXSD6j2h4BBjNnnyI2JRHkq iu0A27ANzqZrHx8rRipFcU9gJqLtBfA= =8/ed -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)
Hi, On Tue, May 10, 2011 at 11:52, Martijn Faassen faas...@startifact.com wrote: Hi there, On 05/10/2011 06:55 AM, Andreas Jung wrote: Constructive criticism and feedback is welcome _now_. Application servers has Zope BlueBream. [...] Speaking of http://beta.zope.org/the-world-of-zope We at Nexedi would appreciate if ERP5 was mentioned on that page as well. Possibly in a Zope Based Applications section (where Zenoss could also fit nicely). Something like: ERP5 is a full featured Open Source Enterprise Resource Planning (ERP) solution including customer relationship management (CRM), production management (MRP), supply chain management (SCM), product design management (PDM), accounting, human resources, e-commerce and many others. Link: http://www.erp5.com/ Thanks, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] plone 4.1: can not access plone 3.5 site after startup
I usually saw this error when some of the objects persisted in the ZODB have references to (i.e. they directly provide) interfaces that are not there in the code anymore anymore, such as when an interface class is removed or moved to another module or package. It can be solved by providing the old interface in the same place in the 'module/package' namespace. Or by removing the interface reference from the object in the old environment before starting the code in the new environment. Incidentally, I'm of the opinion that these kinds of errors should be captured by either zope.interface or by ZODB, logged as 'ERROR', and the object returned without the faulty interface, but that seems to require either adding knowledge about zope.interface to ZODB or vice-versa. Cheers, On Wed, Mar 2, 2011 at 12:07, robert rottermann rob...@redcor.ch wrote: Hi there, I created a 4.1a3 buildout and added all needed products, of which I had to adapt some to be able to start at all. Then I copied the data.fs of a 3.5x site. Now in the ZMI, when I want to navigate to the plone 3.5 folder I get the following error: What can I do to fix that? Do I have to prepare the Data.fs somehow? thanks robert 2011-03-02 11:57:55 ERROR Zope.SiteErrorLog 1299063475.730.425785426825 http://localhost:8481/focus/focus Traceback (innermost last): Module ZPublisher.Publish, line 115, in publish Module ZPublisher.BaseRequest, line 437, in traverse Module ZPublisher.BeforeTraverse, line 97, in __call__ Module Products.CMFCore.PortalObject, line 78, in __before_publishing_traverse__ Module zope.event, line 23, in notify Module zope.component.event, line 24, in dispatch Module zope.component._api, line 136, in subscribers Module zope.component.registry, line 321, in subscribers Module zope.interface.adapter, line 585, in subscribers Module zope.component.event, line 32, in objectEventNotify Module zope.component._api, line 136, in subscribers Module zope.component.registry, line 321, in subscribers Module zope.interface.adapter, line 585, in subscribers Module plone.browserlayer.layer, line 14, in mark_layer Module zope.component._api, line 179, in getAllUtilitiesRegisteredFor Module zope.component.registry, line 176, in getAllUtilitiesRegisteredFor Module ZODB.Connection, line 859, in setstate Module ZODB.Connection, line 913, in _setstate Module ZODB.serialize, line 613, in setGhostState Module zope.component.persistentregistry, line 40, in __setstate__ Module zope.interface.adapter, line 91, in _createLookup Module zope.interface.adapter, line 439, in __init__ Module zope.interface.adapter, line 476, in init_extendors Module zope.interface.adapter, line 480, in add_extendor AttributeError: type object 'IDatabaseSettings' has no attribute '__iro__' 2011-03-02 11:57:55 WARNING OFS.Uninstalled Could not import class 'IThemeSpecific' from module 'focus.theme.browser.interfaces' 2011-03-02 11:57:55 WARNING OFS.Uninstalled Could not import class 'IFocViewletManager' from module 'focus.theme.browser.interfaces' 2011-03-02 11:57:55 ERROR ZODB.Connection Couldn't load state for 0x19746b Traceback (most recent call last): File /home/zope/focus4/eggs/ZODB3-3.10.1-py2.6-linux-i686.egg/ZODB/Connection.py, line 859, in setstate self._setstate(obj) File /home/zope/focus4/eggs/ZODB3-3.10.1-py2.6-linux-i686.egg/ZODB/Connection.py, line 913, in _setstate self._reader.setGhostState(obj, p) File /home/zope/focus4/eggs/ZODB3-3.10.1-py2.6-linux-i686.egg/ZODB/serialize.py, line 613, in setGhostState obj.__setstate__(state) File /home/zope/focus4/eggs/zope.component-3.10.0-py2.6.egg/zope/component/persistentregistry.py, line 40, in __setstate__ self._createLookup() File /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py, line 91, in _createLookup self._v_lookup = self.LookupClass(self) File /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py, line 439, in __init__ self.init_extendors() File /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py, line 476, in init_extendors self.add_extendor(p) File /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py, line 480, in add_extendor for i in provided.__iro__: AttributeError: type object 'IDatabaseSettings' has no attribute '__iro__' ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug day and developer meeting today at 15:00 UTC
This being PloneConf week, it's not surprising the attendance was even lower than usual. On Wed, Oct 27, 2010 at 08:55, Christian Theune c...@gocept.com wrote: Hi, On 10/26/2010 09:14 AM, Christian Theune wrote: [...] This week my job of summarizing is suprisingly easy: nothing to summarize as I was the only attendee of the meeting. So, just in case: if you're not happy with the topics I propose, please feel free to suggest others or just walk in. I'm happy to provide the regular space (and time) and am open to any issues regarding zope-dev. ... ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.12/doc/CHANGES.rst Missing changelog for the ImageFile warning
Log message for revision 114755: Missing changelog for the ImageFile warning Changed: U Zope/branches/2.12/doc/CHANGES.rst -=- Modified: Zope/branches/2.12/doc/CHANGES.rst === --- Zope/branches/2.12/doc/CHANGES.rst 2010-07-14 15:14:17 UTC (rev 114754) +++ Zope/branches/2.12/doc/CHANGES.rst 2010-07-14 15:15:36 UTC (rev 114755) @@ -28,7 +28,14 @@ - LP #143273: Enable the dtml-var modifiers url_quote, url_unquote, url_quote_plus and url_unquote_plus to handle unicode strings. +Features Added +++ +- Warn when App.ImageFile.ImageFile receives a relative path with no prefix, + and then has to assume the path to be relative to software home. This + behaviour is deprecated as packages can be factored out to their own + distribution, making the software home relative path meaningless. + 2.12.9 (2010-07-13) --- ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/src/App/ Warn on App.ImageFile.ImageFile deprecated assumption of software_home
Log message for revision 114749:
Warn on App.ImageFile.ImageFile deprecated assumption of software_home
Changed:
U Zope/branches/2.12/src/App/ImageFile.py
U Zope/branches/2.12/src/App/config.py
A Zope/branches/2.12/src/App/tests/testImageFile.py
-=-
Modified: Zope/branches/2.12/src/App/ImageFile.py
===
--- Zope/branches/2.12/src/App/ImageFile.py 2010-07-14 14:58:01 UTC (rev
114748)
+++ Zope/branches/2.12/src/App/ImageFile.py 2010-07-14 15:07:11 UTC (rev
114749)
@@ -18,6 +18,7 @@
import os.path
import stat
import time
+import warnings
from AccessControl.SecurityInfo import ClassSecurityInfo
from Acquisition import Explicit
@@ -34,6 +35,13 @@
os.path.join(os.path.dirname(Zope2.__file__), os.path.pardir)
)
+NON_PREFIX_WARNING = ('Assuming image location to be present in the Zope2 '
+ 'distribution. This is deprecated and might lead to '
+ 'broken code if the directory in question is moved '
+ 'to another distribution. Please provide either an '
+ 'absolute file system path or a prefix. Support for '
+ 'relative filenames without a prefix might be '
+ 'dropped in a future Zope2 release.')
class ImageFile(Explicit):
Image objects stored in external files.
@@ -43,9 +51,12 @@
def __init__(self, path, _prefix=None):
import Globals # for data
if _prefix is None:
-_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
+_prefix=getattr(getConfiguration(), 'softwarehome', None) or PREFIX
+if not os.path.isabs(path):
+warnings.warn(NON_PREFIX_WARNING, UserWarning, 2 )
elif type(_prefix) is not type(''):
_prefix=package_home(_prefix)
+# _prefix is ignored if path is absolute
path = os.path.join(_prefix, path)
self.path=path
if Globals.DevelopmentMode:
Modified: Zope/branches/2.12/src/App/config.py
===
--- Zope/branches/2.12/src/App/config.py2010-07-14 14:58:01 UTC (rev
114748)
+++ Zope/branches/2.12/src/App/config.py2010-07-14 15:07:11 UTC (rev
114749)
@@ -36,7 +36,7 @@
def setConfiguration(cfg):
Set the global configuration object.
-Legacy sources of common configuraiton values are updated to
+Legacy sources of common configuration values are updated to
reflect the new configuration; this may be removed in some future
version.
Added: Zope/branches/2.12/src/App/tests/testImageFile.py
===
--- Zope/branches/2.12/src/App/tests/testImageFile.py
(rev 0)
+++ Zope/branches/2.12/src/App/tests/testImageFile.py 2010-07-14 15:07:11 UTC
(rev 114749)
@@ -0,0 +1,45 @@
+import unittest
+import os.path
+import App
+from Testing.ZopeTestCase.warnhook import WarningsHook
+
+
+class TestImageFile(unittest.TestCase):
+
+def setUp(self):
+# ugly: need to save the old App.config configuration value since
+# ImageFile might read it and trigger setting it to the default value
+self.oldcfg = App.config._config
+self.warningshook = WarningsHook()
+self.warningshook.install()
+
+def tearDown(self):
+self.warningshook.uninstall()
+# ugly: need to restore configuration, or lack thereof
+App.config._config = self.oldcfg
+
+def test_warn_on_software_home_default(self):
+App.ImageFile.ImageFile('App/www/zopelogo.jpg')
+self.assertEquals(self.warningshook.warnings.pop()[0],
+ App.ImageFile.NON_PREFIX_WARNING)
+
+def test_no_warn_on_absolute_path(self):
+path = os.path.join(os.path.dirname(App.__file__),
+'www','zopelogo.jpg')
+App.ImageFile.ImageFile(path)
+self.failIf(self.warningshook.warnings)
+
+def test_no_warn_on_path_as_prefix(self):
+prefix = os.path.dirname(App.__file__)
+App.ImageFile.ImageFile('www/zopelogo.jpg', prefix)
+self.failIf(self.warningshook.warnings)
+
+def test_no_warn_on_namespace_as_prefix(self):
+prefix = App.__dict__ # same as calling globals() inside the App module
+App.ImageFile.ImageFile('www/zopelogo.jpg', prefix)
+self.failIf(self.warningshook.warnings)
+
+def test_suite():
+return unittest.TestSuite((
+unittest.makeSuite(TestImageFile),
+))
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Warn on App.ImageFile.ImageFile deprecated assumption of software_home. Forward ported 114749 from 2.12 branch
Log message for revision 114757:
Warn on App.ImageFile.ImageFile deprecated assumption of software_home.
Forward ported 114749 from 2.12 branch
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/App/ImageFile.py
U Zope/trunk/src/App/config.py
A Zope/trunk/src/App/tests/testImageFile.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2010-07-14 15:19:05 UTC (rev 114756)
+++ Zope/trunk/doc/CHANGES.rst 2010-07-14 15:46:50 UTC (rev 114757)
@@ -36,6 +36,11 @@
Features Added
++
+- Warn when App.ImageFile.ImageFile receives a relative path with no prefix,
+ and then has to assume the path to be relative to software home. This
+ behaviour is deprecated as packages can be factored out to their own
+ distribution, making the software home relative path meaningless.
+
- Updated packages:
- ZODB3 = 3.10.0b2
Modified: Zope/trunk/src/App/ImageFile.py
===
--- Zope/trunk/src/App/ImageFile.py 2010-07-14 15:19:05 UTC (rev 114756)
+++ Zope/trunk/src/App/ImageFile.py 2010-07-14 15:46:50 UTC (rev 114757)
@@ -18,6 +18,7 @@
import os.path
import stat
import time
+import warnings
from AccessControl.class_init import InitializeClass
from AccessControl.SecurityInfo import ClassSecurityInfo
@@ -34,6 +35,13 @@
os.path.join(os.path.dirname(Zope2.__file__), os.path.pardir)
)
+NON_PREFIX_WARNING = ('Assuming image location to be present in the Zope2 '
+ 'distribution. This is deprecated and might lead to '
+ 'broken code if the directory in question is moved '
+ 'to another distribution. Please provide either an '
+ 'absolute file system path or a prefix. Support for '
+ 'relative filenames without a prefix might be '
+ 'dropped in a future Zope2 release.')
class ImageFile(Explicit):
Image objects stored in external files.
@@ -43,9 +51,12 @@
def __init__(self, path, _prefix=None):
import Globals # for data
if _prefix is None:
-_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
+_prefix=getattr(getConfiguration(), 'softwarehome', None) or PREFIX
+if not os.path.isabs(path):
+warnings.warn(NON_PREFIX_WARNING, UserWarning, 2 )
elif type(_prefix) is not type(''):
_prefix=package_home(_prefix)
+# _prefix is ignored if path is absolute
path = os.path.join(_prefix, path)
self.path=path
if Globals.DevelopmentMode:
Modified: Zope/trunk/src/App/config.py
===
--- Zope/trunk/src/App/config.py2010-07-14 15:19:05 UTC (rev 114756)
+++ Zope/trunk/src/App/config.py2010-07-14 15:46:50 UTC (rev 114757)
@@ -36,7 +36,7 @@
def setConfiguration(cfg):
Set the global configuration object.
-Legacy sources of common configuraiton values are updated to
+Legacy sources of common configuration values are updated to
reflect the new configuration; this may be removed in some future
version.
Copied: Zope/trunk/src/App/tests/testImageFile.py (from rev 114749,
Zope/branches/2.12/src/App/tests/testImageFile.py)
===
--- Zope/trunk/src/App/tests/testImageFile.py (rev 0)
+++ Zope/trunk/src/App/tests/testImageFile.py 2010-07-14 15:46:50 UTC (rev
114757)
@@ -0,0 +1,45 @@
+import unittest
+import os.path
+import App
+from Testing.ZopeTestCase.warnhook import WarningsHook
+
+
+class TestImageFile(unittest.TestCase):
+
+def setUp(self):
+# ugly: need to save the old App.config configuration value since
+# ImageFile might read it and trigger setting it to the default value
+self.oldcfg = App.config._config
+self.warningshook = WarningsHook()
+self.warningshook.install()
+
+def tearDown(self):
+self.warningshook.uninstall()
+# ugly: need to restore configuration, or lack thereof
+App.config._config = self.oldcfg
+
+def test_warn_on_software_home_default(self):
+App.ImageFile.ImageFile('App/www/zopelogo.jpg')
+self.assertEquals(self.warningshook.warnings.pop()[0],
+ App.ImageFile.NON_PREFIX_WARNING)
+
+def test_no_warn_on_absolute_path(self):
+path = os.path.join(os.path.dirname(App.__file__),
+'www','zopelogo.jpg')
+App.ImageFile.ImageFile(path)
+self.failIf(self.warningshook.warnings)
+
+def test_no_warn_on_path_as_prefix(self):
+prefix = os.path.dirname(App.__file__)
+App.ImageFile.ImageFile('www/zopelogo.jpg', prefix)
+self.failIf(self.warningshook.warnings)
+
+def
Re: [Zope-dev] ZEO TempStorage: Odd behavior on ZEO restart
On Wed, Jul 14, 2010 at 19:22, Benji York be...@benjiyork.com wrote: [...] Let me make sure I understand your setup: you have a TemporaryStorage running on a central server that is exposed via ZEO to clients. Right? So, when the ZEO server restarts the temp storage is reset (it's contents don't survive a restart by design), but the clients don't know all the objects they know about in the temp storage just disappeared. Therefore when they go to load one (because it wasn't in their object or ZEO caches), the load fails. Not surprising really. What could be surprising is that, since the objects are not in the object cache or the ZEO cache, how can the clients 'know' about them to request them? And the answer is probably that there are other objects which ARE in the object cache, or the ZEO cache and that hold references (ghost objects in the case of the object-cache) to the objects in the zeo-distributed temporary storage. So, perhaps, Sebastian can avoid a Zope restart if he finds a way to flush all caches. Flushing the object caches is easy, it's in the Control_Panel. Flushing the ZEO cache is something else. Perhaps he can run with a 0-sized ZEO cache for the TempStorages? Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Hi,
The latest Zope 2.12.9 release broke the last release of Products.ZMySQLDA.
To demonstrate, bootstrap and run the attached buildout, then run:
$ bin/py -c import Shared.DC.ZRDB, Products.ZMySQLDA
You'll get the following traceback:
Traceback (most recent call last):
File bin/py, line 107, in module
exec _val
File string, line 1, in module
File
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/__init__.py,
line 90, in module
import DA
File
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/DA.py,
line 243, in module
os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))}
File
/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/App/ImageFile.py,
line 77, in __init__
stat_info = os.stat(path)
OSError: [Errno 2] No such file or directory:
'/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/Shared/DC/ZRDB/www/DBAdapterFolder_icon.gif'
Edit buildout.cfg and switch the extends directive to the commented
out 2.12.8 tag and see that the above command shows no error, only a
deprecation warning that is unrelated to the breakage above.
Internal buildbots that tracked the 2.12 branch notified me of this
problem, but in between catching up with all the traffic for the
mailing lists and the Zope commit, and a day job, I didn't have enough
time to track down the issue before the 2.12.9 release was made: there
was less than 4 days between spinning off Products.ZSQLMethods and the
new 2.12 release.
The most trivial fix seems fairly obvious: ZMySQLDA should carry its
own icon, but in any case, Zope 2.12 should not break compatibility in
the middle of a stable series. I strongly suspect other Zope2 DB
adapters to suffer from the same problem.
I'm not sure what the proper fix should be. App.ImageFile.ImageFile
could grow support for icons outside of software_home, or perhaps the
spinning-off of Shared.DC.ZRDB should be delayed to the 2.13 series
only, but in any case the 2.12 branch should be a safe upgrade for
third party code as much as reasonably possible.
suggestions?
Cheers,
Leo
buildout.cfg
Description: application/httpd-cgi
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Hi
On Tue, Jul 13, 2010 at 12:44, Hanno Schlichting ha...@hannosch.eu wrote:
[...]
You'll get the following traceback:
Traceback (most recent call last):
File bin/py, line 107, in module
exec _val
File string, line 1, in module
File
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/__init__.py,
line 90, in module
import DA
File
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/DA.py,
line 243, in module
os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))}
File
/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/App/ImageFile.py,
line 77, in __init__
stat_info = os.stat(path)
OSError: [Errno 2] No such file or directory:
'/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/Shared/DC/ZRDB/www/DBAdapterFolder_icon.gif'
The most trivial fix seems fairly obvious: ZMySQLDA should carry its
own icon, but in any case, Zope 2.12 should not break compatibility in
the middle of a stable series. I strongly suspect other Zope2 DB
adapters to suffer from the same problem.
We documented it pretty clearly in the Zope 2.12.0 release notes, that
you can no longer rely on software home or zope home. See for example
http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#fully-eggified
The code should have long been changed to import Shared.DC.ZRDB and
then os.path.join(ZRDB.__file__, 'www', 'DBAdapterFolder_icon.gif') or
better yet use its own icon. Both of these would have worked with all
2.12.x releases.
the call that failed is this:
ImageFile(os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))
There is no explicit mention of software home anywhere, and there
was no warning that this API was being used in a deprecated way.
In fact, the use of software home happens inside ImageFile itself:
def __init__(self, path, _prefix=None):
import Globals # for data
if _prefix is None:
_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
elif type(_prefix) is not type(''):
_prefix=package_home(_prefix)
Of course I and most people on this list can read the ImageFile() call
above and probably get a good hunch that sofware_home is being assumed
somewhere, but a cursory reading of the call could also imply that a
data file is simply being read relative to the Zope2 package location,
and that this is supported behaviour of the ImageFile class.
I'm not sure what the proper fix should be. App.ImageFile.ImageFile
could grow support for icons outside of software_home, or perhaps the
spinning-off of Shared.DC.ZRDB should be delayed to the 2.13 series
only, but in any case the 2.12 branch should be a safe upgrade for
third party code as much as reasonably possible.
We don't make guarantees on internals. Zope 2 always had a policy of
allowing minor changes and new features to occur in the stable release
series. It's not just pure bugfix releases.
And I'm not disagreeing with the policy, but it can be argued that
depending on the location of *data* files inside the Zope2 package is
not necessarily relying on guarantees on internals.
I think in this case the code in Products.ZMySQLDA should be changed
to be compatible with Zope 2.12.
Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs
that do rely on software_home) should give a clear warning when
software_home is assumed, since it is the one assuming it. The
exception raised by the ImageFile call now gives no clue on what
actually went wrong and what a developer should do about it.
Cheers,
Leo
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
On Tue, Jul 13, 2010 at 14:46, Hanno Schlichting ha...@hannosch.eu wrote:
On Tue, Jul 13, 2010 at 7:05 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
And I'm not disagreeing with the policy, but it can be argued that
depending on the location of *data* files inside the Zope2 package is
not necessarily relying on guarantees on internals.
I'd call anything that relies on a specific file system layout to be
internals. We only make guarantees on the semantics of the Python
import system, not how packages and modules are stitched together in
distributions and end up on the file system.
Considering that the Zope source code has a dozen examples of
App.ImageFile.ImageFile being used without a prefix (ex. OFS.misc_),
I think third party developers should be excused to think they could
follow the lead and expect their packages not to break during a stable
series.
I still think we should give them at least the 2.12 series to stop
using ImageFile incorrectly without breaking their code, but I won't
belabor the point any longer.
Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs
that do rely on software_home) should give a clear warning when
software_home is assumed, since it is the one assuming it. The
exception raised by the ImageFile call now gives no clue on what
actually went wrong and what a developer should do about it.
I agree with that. I thought the call to software home was being made
inside ZMySQLDA and not in Zope 2 code.
The attached patch adds such a warning, and also reveals where Zope2
commits the same sins. If there are no objections I'll commit it to
2.12 and trunk.
Finally, I'd like to ask that, when major changes land in a stable
series (like the spinning off of a whole package), that we allow at
least a week or two to pass before making a release, so people who
have test runners for their apps running against a stable repository
branch have time to adapt to the changes
Cheers,
Leo
Index: src/App/config.py
===
--- src/App/config.py (revisão 114644)
+++ src/App/config.py (cópia de trabalho)
@@ -36,7 +36,7 @@
def setConfiguration(cfg):
Set the global configuration object.
-Legacy sources of common configuraiton values are updated to
+Legacy sources of common configuration values are updated to
reflect the new configuration; this may be removed in some future
version.
Index: src/App/tests/testImageFile.py
===
--- src/App/tests/testImageFile.py (revisão 0)
+++ src/App/tests/testImageFile.py (revisão 0)
@@ -0,0 +1,28 @@
+import unittest
+import App
+from Testing.ZopeTestCase.warnhook import WarningsHook
+
+
+class TestImageFile(unittest.TestCase):
+
+def setUp(self):
+# ugly: need to save the old App.config configuration value since
+# ImageFile might read it and trigger setting it to the default value
+self.oldcfg = App.config._config
+self.warningshook = WarningsHook()
+self.warningshook.install()
+
+def tearDown(self):
+self.warningshook.uninstall()
+# ugly: need to restore configuration, or lack thereof
+App.config._config = self.oldcfg
+
+def test_warn_on_software_home_default(self):
+App.ImageFile.ImageFile('App/www/zopelogo.jpg')
+self.assertEquals(self.warningshook.warnings.pop()[0],
+ App.ImageFile.NON_PREFIX_WARNING)
+
+def test_suite():
+return unittest.TestSuite((
+unittest.makeSuite(TestImageFile),
+))
Index: src/App/ImageFile.py
===
--- src/App/ImageFile.py (revisão 114644)
+++ src/App/ImageFile.py (cópia de trabalho)
@@ -18,6 +18,7 @@
import os.path
import stat
import time
+import warnings
from AccessControl.SecurityInfo import ClassSecurityInfo
from Acquisition import Explicit
@@ -34,6 +35,13 @@
os.path.join(os.path.dirname(Zope2.__file__), os.path.pardir)
)
+NON_PREFIX_WARNING = ('Assuming image location to be present in the Zope2 '
+ 'distribution. This is deprecated and might lead to '
+ 'broken code if the directory in question is moved '
+ 'to another distribution. Please provide either an '
+ 'absolute file system path or a prefix. Support for '
+ 'relative filenames without a prefix might be '
+ 'dropped in a future Zope2 release.')
class ImageFile(Explicit):
Image objects stored in external files.
@@ -43,9 +51,12 @@
def __init__(self, path, _prefix=None):
import Globals # for data
if _prefix is None:
-_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
+_prefix=getattr(getConfiguration(), 'softwarehome', None) or PREFIX
+if not os.path.isabs(path
[Zope-Checkins] SVN: Zope/branches/rochael-TM_sortKey/ branch has been merged
Log message for revision 113726: branch has been merged Changed: D Zope/branches/rochael-TM_sortKey/ -=- ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] SVN: Zope/branches/2.12/ ReST changes, and it's a new year already
This should've gone to zope-dev too. On Sun, Jun 20, 2010 at 23:14, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Hi Tres, That file was brand new from this year. I just copied a copyright boilerplate that contained 2009 and pasted into the file before adding it to the repository. On Sat, Jun 19, 2010 at 10:31, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leonardo Rochael Almeida wrote: Log message for revision 113624: ReST changes, and it's a new year already Changed: U Zope/branches/2.12/doc/CHANGES.rst U Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py -=- Modified: Zope/branches/2.12/doc/CHANGES.rst === --- Zope/branches/2.12/doc/CHANGES.rst 2010-06-18 19:33:34 UTC (rev 113623) +++ Zope/branches/2.12/doc/CHANGES.rst 2010-06-18 19:38:08 UTC (rev 113624) @@ -38,9 +38,9 @@ - Missing = 2.13.1 - Persistence = 2.13.2 -- Added setSortKey() method to the Shared.DC.ZRDB.TM.TM class +- Added ``setSortKey()`` method to the ``Shared.DC.ZRDB.TM.TM`` class to allow database connections to specify the commit order without - needing to override the sortKey() method. + needing to override the ``sortKey()`` method. 2.12.7 (2010-06-13) --- Modified: Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py === --- Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 19:33:34 UTC (rev 113623) +++ Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 19:38:08 UTC (rev 113624) @@ -1,6 +1,6 @@ ## # -# Copyright (c) 2009 Zope Foundation and Contributors. +# Copyright (c) 2010 Zope Foundation and Contributors. # # This software is subject to the provisions of the Zope Public License, # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. We don't replace the original copyright date ever, but add new dates for changes which introduce copyrightable material (i.e., non-trival new code). If such changes apply in this case, then the header should be: # Copyright (c) 2009, 2010 Zope Foundation and Contributors. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Design http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwcxp4ACgkQ+gerLs4ltQ78BwCfZLPDoWvWZchqo27IB34pOFH2 R+cAn3kqAgE2Fg6TWT6/MkqjCSyjq3xb =/uib -END PGP SIGNATURE- ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/rochael-TM_sortKey/doc/CHANGES.rst record setSortKey() changes
Log message for revision 113621: record setSortKey() changes Changed: U Zope/branches/rochael-TM_sortKey/doc/CHANGES.rst -=- Modified: Zope/branches/rochael-TM_sortKey/doc/CHANGES.rst === --- Zope/branches/rochael-TM_sortKey/doc/CHANGES.rst2010-06-18 18:27:43 UTC (rev 113620) +++ Zope/branches/rochael-TM_sortKey/doc/CHANGES.rst2010-06-18 19:04:36 UTC (rev 113621) @@ -38,6 +38,10 @@ - Missing = 2.13.1 - Persistence = 2.13.2 +- Added setSortKey() method to the Shared.DC.ZRDB.TM.TM class + to allow database connections to specify the commit order without + needing to override the sortKey() method. + 2.12.7 (2010-06-13) --- ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/ merge branch rochael-TM_sortKey: add a setSortKey method to Shared.setSortKey() method to Shared.DC.ZRDB.TM.TM
Log message for revision 113622: merge branch rochael-TM_sortKey: add a setSortKey method to Shared.setSortKey() method to Shared.DC.ZRDB.TM.TM Changed: U Zope/branches/2.12/doc/CHANGES.rst U Zope/branches/2.12/src/Shared/DC/ZRDB/TM.py A Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py -=- Modified: Zope/branches/2.12/doc/CHANGES.rst === --- Zope/branches/2.12/doc/CHANGES.rst 2010-06-18 19:04:36 UTC (rev 113621) +++ Zope/branches/2.12/doc/CHANGES.rst 2010-06-18 19:18:30 UTC (rev 113622) @@ -38,6 +38,10 @@ - Missing = 2.13.1 - Persistence = 2.13.2 +- Added setSortKey() method to the Shared.DC.ZRDB.TM.TM class + to allow database connections to specify the commit order without + needing to override the sortKey() method. + 2.12.7 (2010-06-13) --- Modified: Zope/branches/2.12/src/Shared/DC/ZRDB/TM.py === --- Zope/branches/2.12/src/Shared/DC/ZRDB/TM.py 2010-06-18 19:04:36 UTC (rev 113621) +++ Zope/branches/2.12/src/Shared/DC/ZRDB/TM.py 2010-06-18 19:18:30 UTC (rev 113622) @@ -26,7 +26,7 @@ needed at the start of a transaction. A subclass that uses locking during transaction commit must -defined a sortKey() method. +define a sortKey() method. _registered=None @@ -66,14 +66,19 @@ tpc_abort = abort +# Most DA's talking to RDBMS systems do not care about commit order, so +# return the constant 1 +_sort_key = 1 + def sortKey(self, *ignored): - The sortKey method is used for recent ZODB compatibility which -needs to have a known commit order for lock acquisition. Most -DA's talking to RDBMS systems do not care about commit order, so -return the constant 1 + The sortKey method is used by ZODB to have a known commit order for +lock acquisition. -return 1 +return self._sort_key +def setSortKey(self, sort_key): +self._sort_key = sort_key + class Surrogate: def __init__(self, db): Copied: Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py (from rev 113621, Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/tests/testTM.py) === --- Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py (rev 0) +++ Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 19:18:30 UTC (rev 113622) @@ -0,0 +1,29 @@ +## +# +# Copyright (c) 2009 Zope Foundation and Contributors. +# +# This software is subject to the provisions of the Zope Public License, +# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. +# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED +# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS +# FOR A PARTICULAR PURPOSE +# +## + +from unittest import TestCase, TestSuite, makeSuite +from Shared.DC.ZRDB.TM import TM + +class TestTM(TestCase): + +def test_sortKey(self): +tm = TM() +# the default Transaction Manager should have .sortKey() of 1 for +# backward compatibility +self.assertEquals(tm.sortKey(), 1) +# but the sortKey() should be adjustable +tm.setSortKey(()) +self.assertEquals(tm.sortKey(), ()) + +def test_suite(): +return TestSuite((makeSuite(TestTM),)) ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ merge branch rochael-TM_sortKey: add a setSortKey method to Shared.setSortKey() method to Shared.DC.ZRDB.TM.TM
Log message for revision 113623: merge branch rochael-TM_sortKey: add a setSortKey method to Shared.setSortKey() method to Shared.DC.ZRDB.TM.TM Changed: U Zope/trunk/doc/CHANGES.rst U Zope/trunk/src/Shared/DC/ZRDB/TM.py A Zope/trunk/src/Shared/DC/ZRDB/tests/testTM.py -=- Modified: Zope/trunk/doc/CHANGES.rst === --- Zope/trunk/doc/CHANGES.rst 2010-06-18 19:18:30 UTC (rev 113622) +++ Zope/trunk/doc/CHANGES.rst 2010-06-18 19:33:34 UTC (rev 113623) @@ -145,6 +145,10 @@ - ZCTextIndex query parser treats fullwidth space characters defined in Unicode as valid white space. +- Added ``setSortKey()`` method to the ``Shared.DC.ZRDB.TM.TM`` class + to allow database connections to specify the commit order without + needing to override the ``sortKey()`` method. + - Updated packages: - Jinja2 = 2.5.0 Modified: Zope/trunk/src/Shared/DC/ZRDB/TM.py === --- Zope/trunk/src/Shared/DC/ZRDB/TM.py 2010-06-18 19:18:30 UTC (rev 113622) +++ Zope/trunk/src/Shared/DC/ZRDB/TM.py 2010-06-18 19:33:34 UTC (rev 113623) @@ -26,7 +26,7 @@ needed at the start of a transaction. A subclass that uses locking during transaction commit must -defined a sortKey() method. +define a sortKey() method. _registered=None @@ -66,14 +66,19 @@ tpc_abort = abort +# Most DA's talking to RDBMS systems do not care about commit order, so +# return the constant 1 +_sort_key = 1 + def sortKey(self, *ignored): - The sortKey method is used for recent ZODB compatibility which -needs to have a known commit order for lock acquisition. Most -DA's talking to RDBMS systems do not care about commit order, so -return the constant 1 + The sortKey method is used by the transaction subsystem to have a +known commit order for lock acquisition. -return 1 +return self._sort_key +def setSortKey(self, sort_key): +self._sort_key = sort_key + class Surrogate: def __init__(self, db): Copied: Zope/trunk/src/Shared/DC/ZRDB/tests/testTM.py (from rev 113621, Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/tests/testTM.py) === --- Zope/trunk/src/Shared/DC/ZRDB/tests/testTM.py (rev 0) +++ Zope/trunk/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 19:33:34 UTC (rev 113623) @@ -0,0 +1,30 @@ +## +# +# Copyright (c) 2010 Zope Foundation and Contributors. +# +# This software is subject to the provisions of the Zope Public License, +# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. +# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED +# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS +# FOR A PARTICULAR PURPOSE +# +## + +from unittest import TestCase, TestSuite, makeSuite +from Shared.DC.ZRDB.TM import TM + +class TestTM(TestCase): + +def test_sortKey(self): +tm = TM() +# the default Transaction Manager should have .sortKey() of 1 for +# backward compatibility +self.assertEquals(tm.sortKey(), 1) +# but the sortKey() should be adjustable +tm.setSortKey(()) +self.assertEquals(tm.sortKey(), ()) + +def test_suite(): +return TestSuite((makeSuite(TestTM),)) + ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/ ReST changes, and it's a new year already
Log message for revision 113624: ReST changes, and it's a new year already Changed: U Zope/branches/2.12/doc/CHANGES.rst U Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py -=- Modified: Zope/branches/2.12/doc/CHANGES.rst === --- Zope/branches/2.12/doc/CHANGES.rst 2010-06-18 19:33:34 UTC (rev 113623) +++ Zope/branches/2.12/doc/CHANGES.rst 2010-06-18 19:38:08 UTC (rev 113624) @@ -38,9 +38,9 @@ - Missing = 2.13.1 - Persistence = 2.13.2 -- Added setSortKey() method to the Shared.DC.ZRDB.TM.TM class +- Added ``setSortKey()`` method to the ``Shared.DC.ZRDB.TM.TM`` class to allow database connections to specify the commit order without - needing to override the sortKey() method. + needing to override the ``sortKey()`` method. 2.12.7 (2010-06-13) --- Modified: Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py === --- Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 19:33:34 UTC (rev 113623) +++ Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 19:38:08 UTC (rev 113624) @@ -1,6 +1,6 @@ ## # -# Copyright (c) 2009 Zope Foundation and Contributors. +# Copyright (c) 2010 Zope Foundation and Contributors. # # This software is subject to the provisions of the Zope Public License, # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] connection commit ordering
Hi Laurence On Fri, Jun 18, 2010 at 08:06, Laurence Rowe l...@lrowe.co.uk wrote: On 18 June 2010 01:24, Leonardo Rochael Almeida leoroch...@gmail.com wrote: By the way, this issue is completely separate from the two-phase-commit discussion that we had recently, since all the connectors involved here are fully transactional. As you can see here: http://zope3.pov.lt/trac/browser/Zope/trunk/src/Shared/DC/ZRDB/TM.py def tpc_vote(self, *ignored): self._finalize = 1 def tpc_finish(self, *ignored): if self._finalize: try: self._finish() finally: self._registered=0 The transaction manager is only doing one phase commit. It sorts first as it commits in the second phase. If you change the sort order, you lose the guarantee of transactional integrity. For me this means that TM subclasses need to override tpc_vote and implement a proper commit preparation [1] [2] to assure they are correctly participating in the TPC dance. And if that is not the case, but you have, for example, more than one MySQL connector, you are already in a situation where you can't guarantee transactional integrity, so this discussion is actually orthogonal to the sortOrder one. Perhaps a better way to solve this would be to include the zope transaction id in the table, then in the background thread only reindex the queued items with a tid = the current tid of the connection. Possibly, but is there a way to know the id of a transaction that hasn't been committed yet, to store it on MySQL? Besides, when working with multiple mount points, you might have to store multiple TIDs, for all storages involved, or else there should be a global transaction ID that should be recorded everywhere, and I don't see the 'transaction' package providing one. In any case, does anyone oppose the existence of a .setSortKey() on the TM class? Cheers, Leo [1] http://www.postgresql.org/docs/current/static/sql-prepare-transaction.html [2] http://dev.mysql.com/doc/refman/5.0/en/xa.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] connection commit ordering
On Fri, Jun 18, 2010 at 10:55, Hanno Schlichting ha...@hannosch.eu wrote: On Fri, Jun 18, 2010 at 3:32 PM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: In any case, does anyone oppose the existence of a .setSortKey() on the TM class? Your branch looks simple enough. Feel free to merge it to Zope trunk but don't forget to add a change entry in doc/CHANGES.rst Thanks. Can I commit it to Zope 2.12 as well? It is backward compatible and helps us address a bug we see on production. Cheers, ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/rochael-TM_sortKey/ branch for adjustable sortKey() for Shared.DC.ZRDB.TM
Log message for revision 113596: branch for adjustable sortKey() for Shared.DC.ZRDB.TM Changed: A Zope/branches/rochael-TM_sortKey/ -=- ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/ make the result of Shared.DC.ZRDB.TM.TM.sortKey() adjustable
Log message for revision 113597: make the result of Shared.DC.ZRDB.TM.TM.sortKey() adjustable Changed: U Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/TM.py A Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/tests/testTM.py -=- Modified: Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/TM.py === --- Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/TM.py 2010-06-18 00:08:58 UTC (rev 113596) +++ Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/TM.py 2010-06-18 00:17:09 UTC (rev 113597) @@ -26,7 +26,7 @@ needed at the start of a transaction. A subclass that uses locking during transaction commit must -defined a sortKey() method. +define a sortKey() method. _registered=None @@ -66,14 +66,19 @@ tpc_abort = abort +# Most DA's talking to RDBMS systems do not care about commit order, so +# return the constant 1 +_sort_key = 1 + def sortKey(self, *ignored): - The sortKey method is used for recent ZODB compatibility which -needs to have a known commit order for lock acquisition. Most -DA's talking to RDBMS systems do not care about commit order, so -return the constant 1 + The sortKey method is used by ZODB to have a known commit order for +lock acquisition. -return 1 +return self._sort_key +def setSortKey(self, sort_key): +self._sort_key = sort_key + class Surrogate: def __init__(self, db): Added: Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/tests/testTM.py === --- Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/tests/testTM.py (rev 0) +++ Zope/branches/rochael-TM_sortKey/src/Shared/DC/ZRDB/tests/testTM.py 2010-06-18 00:17:09 UTC (rev 113597) @@ -0,0 +1,29 @@ +## +# +# Copyright (c) 2009 Zope Foundation and Contributors. +# +# This software is subject to the provisions of the Zope Public License, +# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. +# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED +# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS +# FOR A PARTICULAR PURPOSE +# +## + +from unittest import TestCase, TestSuite, makeSuite +from Shared.DC.ZRDB.TM import TM + +class TestTM(TestCase): + +def test_sortKey(self): +tm = TM() +# the default Transaction Manager should have .sortKey() of 1 for +# backward compatibility +self.assertEquals(tm.sortKey(), 1) +# but the sortKey() should be adjustable +tm.setSortKey(()) +self.assertEquals(tm.sortKey(), ()) + +def test_suite(): +return TestSuite((makeSuite(TestTM),)) ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] connection commit ordering
Hi, In ERP5[1], which is CMF based, we have a number of strategies for high performance and scalability. One of these is that we have ZSQLCatalog extensively. The other is that we delay execution of potentially expensive operations (like indexing) for background execution. For the latter, we store the information about background tasks to be executed (path to affected object, method to call, serialization and ordering tags) in an SQL table. Background requests (clock-server) then look up the activity table to either distribute the tasks between the nodes of a ZEO cluster or to execute a previously distributed task. In one specific client with a very high volume of transactions, we were experiencing failures in these background executions. We traced it, among other things, to the ordering of connections during commit. Here is what happened. 1. An object in the ZODB 2. the .reindexObject() method of this object schedules a task for the real indexation to the background processes, using a ZMySQLDA connector. 3. The transaction machinery performs the commit, ordering the connections according to the .sortKey() method of each connection: 3.1. All ZMySQLDA connectors involved, since their .sortKey() returns the integer 1 (see Shared.ZRDB.TM.TM.sortKey() ) 3.2. all mounted ClientStorages or FileStorages involved, whose .sortKey()s are strings which sort after integers. If in between 3.1 and 3.2 a background process tries to execute the scheduled activity commited on 3.1, then it will see the new information on the 'background-tasks' table but the object to be indexed will not yet be in the ZODB causing the activity to fail. The solution we found involves changing the result of .sortKey() for the transaction manager of the database connection, but we can't do this globally for all connectors, otherwise we could have the connector for the SQL based catalog being committed after the connector for the background tasks, and we would end up with a similar error situation. The adapter for the background tasks must necessarily commit after all data needed by the background tasks was already committed. By the way, this issue is completely separate from the two-phase-commit discussion that we had recently, since all the connectors involved here are fully transactional. At Nexedi, we concluded that we might need to be able to customize the sortKey() per database-adapter instance in Zope, since different adapters might need to be committed in different order. Unfortunately it looks like the connection sorting machinery was intended only to obtain a consistent ordering to avoid deadlocks from competing clients, instead of establishing dependency relationships between the connectors, since there seems to be no standard on what the sorting keys should be (they're integers for Shared.ZRDB.TM.TM and strings for ZODB storages). To make this easier without requiring reimplementation of the .sortKey() method in all database connectors, I took the liberty of creating a branch of Zope 2.12 [2] that adds a .setSortKey() method to Shared.ZRDB.TM.TM and I'd welcome opinions. In any case, we were left wondering if others have faced similar issues with the commit order and if others have any opinions on this problem. Cheers, Leo [1] http://erp5.com/ [2] http://svn.zope.org/repos/main/Zope/branches/rochael-TM_sortKey/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Launchpad gardening
Thanks Tres and Sidnei, My questions were intended to go to the list anyway. Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit? For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit? Wouldn't it be nice if it was possible? Cheers, Leo On Thu, Apr 15, 2010 at 12:34, Sidnei da Silva sidnei.da.si...@gmail.com wrote: On Thu, Apr 15, 2010 at 12:17 PM, Tres Seaver tsea...@palladion.com wrote: snip Finally, I push my branch up to Launchpad:: $ bzr push lp:~tseaver/zope.interface/lp_12345 Once the branch is submitted to Launchpad, it is also possible to create a Merge Proposal, which is a step up from a patch. Reviewers can see a live diff on the Merge Proposal that gets updated every time you do a new 'push'. Merge Proposals also have their own state. There's a dashboard for keeping track of pending and approved Merge Proposals, eg: https://launchpad.net/zopetoolkit/+activereviews (the same exists for users: https://launchpad.net/~sidnei/+activereviews) If you have bzrtools installed, you can use the 'bzr lp-submit' command to create a Merge Proposal from the command line, IIRC. It might seem like extra work at first, but once you get used to using Merge Proposals to track work that's pending a merge it pays off very quickly. snip A branch made using 'bzr checkout' is bound to the SVN repository: commits are automatically pushed back to the master. When working in bzr, I really like the ability to batch up local commits, so I often create a local branch of the bound one, hack on it with multiple commits, and then push back to the bound branch. That's how I work too, even with branches stored in bzr, by having a 'trunk' branch that is bound it saves you a few steps when merging work back into the main tree. For people that prefer to be really explicit, you can use 'bzr branch svn+ssh://...' instead of 'bzr checkout' to create an unbound branch by default. You can also use 'bzr bind' and 'bzr unbind' to switch between bound and unbound. -- Sidnei ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.12/src/Products/StandardCacheManagers/ fix lp #534653, reset *CacheManager module level cache id on clone
Log message for revision 109929:
fix lp #534653, reset *CacheManager module level cache id on clone
Changed:
U
Zope/branches/2.12/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
U Zope/branches/2.12/src/Products/StandardCacheManagers/RAMCacheManager.py
A Zope/branches/2.12/src/Products/StandardCacheManagers/configure.zcml
A Zope/branches/2.12/src/Products/StandardCacheManagers/subscribers.py
A
Zope/branches/2.12/src/Products/StandardCacheManagers/tests/test_CacheManagerLocation.py
-=-
Modified:
Zope/branches/2.12/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
===
---
Zope/branches/2.12/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
2010-03-12 15:37:56 UTC (rev 109928)
+++
Zope/branches/2.12/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
2010-03-12 16:07:59 UTC (rev 109929)
@@ -166,12 +166,16 @@
self._settings = {'anonymous_only':1,
'interval':3600,
'notify_urls':()}
-self.__cacheid = '%s_%f' % (id(self), time.time())
+self._resetCacheId()
def getId(self):
' '
return self.id
+security.declarePrivate('_resetCacheId')
+def _resetCacheId(self):
+self.__cacheid = '%s_%f' % (id(self), time.time())
+
security.declarePrivate('ZCacheManager_getCache')
def ZCacheManager_getCache(self):
cacheid = self.__cacheid
Modified:
Zope/branches/2.12/src/Products/StandardCacheManagers/RAMCacheManager.py
===
--- Zope/branches/2.12/src/Products/StandardCacheManagers/RAMCacheManager.py
2010-03-12 15:37:56 UTC (rev 109928)
+++ Zope/branches/2.12/src/Products/StandardCacheManagers/RAMCacheManager.py
2010-03-12 16:07:59 UTC (rev 109929)
@@ -374,12 +374,16 @@
'request_vars': ('AUTHENTICATED_USER',),
'max_age': 3600,
}
-self.__cacheid = '%s_%f' % (id(self), time.time())
+self._resetCacheId()
def getId(self):
' '
return self.id
+security.declarePrivate('_resetCacheId')
+def _resetCacheId(self):
+self.__cacheid = '%s_%f' % (id(self), time.time())
+
ZCacheManager_getCache__roles__ = ()
def ZCacheManager_getCache(self):
cacheid = self.__cacheid
Added: Zope/branches/2.12/src/Products/StandardCacheManagers/configure.zcml
===
--- Zope/branches/2.12/src/Products/StandardCacheManagers/configure.zcml
(rev 0)
+++ Zope/branches/2.12/src/Products/StandardCacheManagers/configure.zcml
2010-03-12 16:07:59 UTC (rev 109929)
@@ -0,0 +1,13 @@
+configure xmlns=http://namespaces.zope.org/zope;
+
+ subscriber
+for=Products.StandardCacheManagers.RAMCacheManager.RAMCacheManager
+ OFS.interfaces.IObjectClonedEvent
+handler=Products.StandardCacheManagers.subscribers.cloned /
+
+ subscriber
+
for=Products.StandardCacheManagers.AcceleratedHTTPCacheManager.AcceleratedHTTPCacheManager
+ OFS.interfaces.IObjectClonedEvent
+handler=Products.StandardCacheManagers.subscribers.cloned /
+
+/configure
Added: Zope/branches/2.12/src/Products/StandardCacheManagers/subscribers.py
===
--- Zope/branches/2.12/src/Products/StandardCacheManagers/subscribers.py
(rev 0)
+++ Zope/branches/2.12/src/Products/StandardCacheManagers/subscribers.py
2010-03-12 16:07:59 UTC (rev 109929)
@@ -0,0 +1,24 @@
+##
+#
+# Copyright (c) 2010 Zope Foundation and Contributors.
+# All Rights Reserved.
+#
+# This software is subject to the provisions of the Zope Public License,
+# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
+# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED
+# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
+# FOR A PARTICULAR PURPOSE.
+#
+##
+ subscribers to events affecting StandardCacheManagers
+
+
+
+def cloned(obj, event):
+
+Reset the Id of the module level cache so the clone gets a different cache
+than its source object
+
+obj._resetCacheId()
+
Added:
Zope/branches/2.12/src/Products/StandardCacheManagers/tests/test_CacheManagerLocation.py
===
---
Zope/branches/2.12/src/Products/StandardCacheManagers/tests/test_CacheManagerLocation.py
(rev 0)
+++
[Zope-Checkins] SVN: Zope/trunk/ forward port r109929: fix for lp #534653
Log message for revision 109931:
forward port r109929: fix for lp #534653
Changed:
_U Zope/trunk/
U
Zope/trunk/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
U Zope/trunk/src/Products/StandardCacheManagers/RAMCacheManager.py
A Zope/trunk/src/Products/StandardCacheManagers/configure.zcml
A Zope/trunk/src/Products/StandardCacheManagers/subscribers.py
A
Zope/trunk/src/Products/StandardCacheManagers/tests/test_CacheManagerLocation.py
-=-
Property changes on: Zope/trunk
___
Added: svn:mergeinfo
+ /Zope/branches/2.12:109929
Modified:
Zope/trunk/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
===
---
Zope/trunk/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
2010-03-12 16:22:28 UTC (rev 109930)
+++
Zope/trunk/src/Products/StandardCacheManagers/AcceleratedHTTPCacheManager.py
2010-03-12 16:28:15 UTC (rev 109931)
@@ -166,12 +166,16 @@
self._settings = {'anonymous_only':1,
'interval':3600,
'notify_urls':()}
-self.__cacheid = '%s_%f' % (id(self), time.time())
+self._resetCacheId()
def getId(self):
' '
return self.id
+security.declarePrivate('_resetCacheId')
+def _resetCacheId(self):
+self.__cacheid = '%s_%f' % (id(self), time.time())
+
security.declarePrivate('ZCacheManager_getCache')
def ZCacheManager_getCache(self):
cacheid = self.__cacheid
Modified: Zope/trunk/src/Products/StandardCacheManagers/RAMCacheManager.py
===
--- Zope/trunk/src/Products/StandardCacheManagers/RAMCacheManager.py
2010-03-12 16:22:28 UTC (rev 109930)
+++ Zope/trunk/src/Products/StandardCacheManagers/RAMCacheManager.py
2010-03-12 16:28:15 UTC (rev 109931)
@@ -374,12 +374,16 @@
'request_vars': ('AUTHENTICATED_USER',),
'max_age': 3600,
}
-self.__cacheid = '%s_%f' % (id(self), time.time())
+self._resetCacheId()
def getId(self):
' '
return self.id
+security.declarePrivate('_resetCacheId')
+def _resetCacheId(self):
+self.__cacheid = '%s_%f' % (id(self), time.time())
+
ZCacheManager_getCache__roles__ = ()
def ZCacheManager_getCache(self):
cacheid = self.__cacheid
Copied: Zope/trunk/src/Products/StandardCacheManagers/configure.zcml (from rev
109929, Zope/branches/2.12/src/Products/StandardCacheManagers/configure.zcml)
===
--- Zope/trunk/src/Products/StandardCacheManagers/configure.zcml
(rev 0)
+++ Zope/trunk/src/Products/StandardCacheManagers/configure.zcml
2010-03-12 16:28:15 UTC (rev 109931)
@@ -0,0 +1,13 @@
+configure xmlns=http://namespaces.zope.org/zope;
+
+ subscriber
+for=Products.StandardCacheManagers.RAMCacheManager.RAMCacheManager
+ OFS.interfaces.IObjectClonedEvent
+handler=Products.StandardCacheManagers.subscribers.cloned /
+
+ subscriber
+
for=Products.StandardCacheManagers.AcceleratedHTTPCacheManager.AcceleratedHTTPCacheManager
+ OFS.interfaces.IObjectClonedEvent
+handler=Products.StandardCacheManagers.subscribers.cloned /
+
+/configure
Copied: Zope/trunk/src/Products/StandardCacheManagers/subscribers.py (from rev
109929, Zope/branches/2.12/src/Products/StandardCacheManagers/subscribers.py)
===
--- Zope/trunk/src/Products/StandardCacheManagers/subscribers.py
(rev 0)
+++ Zope/trunk/src/Products/StandardCacheManagers/subscribers.py
2010-03-12 16:28:15 UTC (rev 109931)
@@ -0,0 +1,24 @@
+##
+#
+# Copyright (c) 2010 Zope Foundation and Contributors.
+# All Rights Reserved.
+#
+# This software is subject to the provisions of the Zope Public License,
+# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
+# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED
+# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
+# FOR A PARTICULAR PURPOSE.
+#
+##
+ subscribers to events affecting StandardCacheManagers
+
+
+
+def cloned(obj, event):
+
+Reset the Id of the module level cache so the clone gets a different cache
+than its source object
+
+obj._resetCacheId()
+
Copied:
Zope/trunk/src/Products/StandardCacheManagers/tests/test_CacheManagerLocation.py
(from rev 109929,
Re: [Zope-dev] New Zope 3 name: BlueBream
On Thu, Jan 7, 2010 at 07:18, Lennart Regebro rege...@gmail.com wrote: On Thu, Jan 7, 2010 at 04:56, Baiju M mba...@zeomega.com wrote: http://www.youtube.com/watch?v=HyG5Qee5wbs Heh, nice! :-) Except that the song in this clip is what weddings in Brazil traditionally play in the part where the bride walks down the aisle with her father. I kept expecting to see either a bride in white gown or another wedding reference to appear somewhere on the video :-) Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.12/ LP #246983: Unicode conflict resolution on variables inside 'string:' expressions
Log message for revision 107725:
LP #246983: Unicode conflict resolution on variables inside 'string:'
expressions
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U
Zope/branches/2.12/src/Products/Five/browser/tests/test_pagetemplatefile.py
U Zope/branches/2.12/src/Products/PageTemplates/Expressions.py
U Zope/branches/2.12/src/Products/PageTemplates/tests/testExpressions.py
U
Zope/branches/2.12/src/Products/PageTemplates/tests/testZopePageTemplate.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
===
--- Zope/branches/2.12/doc/CHANGES.rst 2010-01-05 22:37:00 UTC (rev 107724)
+++ Zope/branches/2.12/doc/CHANGES.rst 2010-01-06 01:31:21 UTC (rev 107725)
@@ -11,6 +11,9 @@
Bugs Fixed
++
+- LP #246983: Enabled unicode conflict resolution on variables inside string:
+ expressions in TALES.
+
- Fixed possible TypeError while sending multipart emails.
- Also look for ZEXP imports within the clienthome directory. This
Modified:
Zope/branches/2.12/src/Products/Five/browser/tests/test_pagetemplatefile.py
===
--- Zope/branches/2.12/src/Products/Five/browser/tests/test_pagetemplatefile.py
2010-01-05 22:37:00 UTC (rev 107724)
+++ Zope/branches/2.12/src/Products/Five/browser/tests/test_pagetemplatefile.py
2010-01-06 01:31:21 UTC (rev 107725)
@@ -37,13 +37,13 @@
from zope.tales.expressions import DeferExpr
from zope.tales.expressions import NotExpr
from zope.tales.expressions import PathExpr
-from zope.tales.expressions import StringExpr
from zope.tales.expressions import Undefs
from zope.tales.pythonexpr import PythonExpr
from zope.contentprovider.tales import TALESProviderExpression
from Products.PageTemplates.DeferExpr import LazyExpr
from Products.PageTemplates.Expressions import TrustedZopePathExpr
from Products.PageTemplates.Expressions import SecureModuleImporter
+from Products.PageTemplates.Expressions import UnicodeAwareStringExpr
vptf = self._makeOne('seagull.pt')
engine = vptf.pt_getEngine()
@@ -51,7 +51,7 @@
self.assertEqual(engine.types['path'], TrustedZopePathExpr)
self.assertEqual(engine.types['exists'], TrustedZopePathExpr)
self.assertEqual(engine.types['nocall'], TrustedZopePathExpr)
-self.assertEqual(engine.types['string'], StringExpr)
+self.assertEqual(engine.types['string'], UnicodeAwareStringExpr)
self.assertEqual(engine.types['python'], PythonExpr)
self.assertEqual(engine.types['not'], NotExpr)
self.assertEqual(engine.types['defer'], DeferExpr)
Modified: Zope/branches/2.12/src/Products/PageTemplates/Expressions.py
===
--- Zope/branches/2.12/src/Products/PageTemplates/Expressions.py
2010-01-05 22:37:00 UTC (rev 107724)
+++ Zope/branches/2.12/src/Products/PageTemplates/Expressions.py
2010-01-06 01:31:21 UTC (rev 107725)
@@ -372,12 +372,26 @@
return False
return ob1 == ob2
+class UnicodeAwareStringExpr(StringExpr):
+
+def __call__(self, econtext):
+vvals = []
+if isinstance(self._expr, unicode):
+# coerce values through the Unicode Conflict Resolver
+evaluate = econtext.evaluateText
+else:
+evaluate = econtext.evaluate
+for var in self._vars:
+v = evaluate(var)
+vvals.append(v)
+return self._expr % tuple(vvals)
+
def createZopeEngine(zpe=ZopePathExpr):
e = ZopeEngine()
e.iteratorFactory = PathIterator
for pt in zpe._default_type_names:
e.registerType(pt, zpe)
-e.registerType('string', StringExpr)
+e.registerType('string', UnicodeAwareStringExpr)
e.registerType('python', ZRPythonExpr.PythonExpr)
e.registerType('not', NotExpr)
e.registerType('defer', DeferExpr)
Modified: Zope/branches/2.12/src/Products/PageTemplates/tests/testExpressions.py
===
--- Zope/branches/2.12/src/Products/PageTemplates/tests/testExpressions.py
2010-01-05 22:37:00 UTC (rev 107724)
+++ Zope/branches/2.12/src/Products/PageTemplates/tests/testExpressions.py
2010-01-06 01:31:21 UTC (rev 107725)
@@ -25,12 +25,20 @@
__allow_access_to_unprotected_subobjects__ = 1
def __call__(self):
return 'dummy'
+
+management_page_charset = 'iso-8859-15'
class DummyDocumentTemplate:
__allow_access_to_unprotected_subobjects__ = 1
isDocTemp = True
def __call__(self, client=None, REQUEST={}, RESPONSE=None, **kw):
return 'dummy'
+
+def absolute_url(self, relative=0):
+url = 'dummy'
+if
[Zope-Checkins] SVN: Zope/trunk/ merge 107725 from 2.12: fix for LP #246983
Log message for revision 107726:
merge 107725 from 2.12: fix for LP #246983
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/Products/Five/browser/tests/test_pagetemplatefile.py
U Zope/trunk/src/Products/PageTemplates/Expressions.py
U Zope/trunk/src/Products/PageTemplates/tests/testExpressions.py
U Zope/trunk/src/Products/PageTemplates/tests/testZopePageTemplate.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2010-01-06 01:31:21 UTC (rev 107725)
+++ Zope/trunk/doc/CHANGES.rst 2010-01-06 01:50:37 UTC (rev 107726)
@@ -125,6 +125,9 @@
Bugs Fixed
++
+- LP #246983: Enabled unicode conflict resolution on variables inside string:
+ expressions in TALES.
+
- Also look for ZEXP imports within the clienthome directory. This
provides a place to put imports that won't be clobbered by buildout
in a buildout-based Zope instance.
Modified: Zope/trunk/src/Products/Five/browser/tests/test_pagetemplatefile.py
===
--- Zope/trunk/src/Products/Five/browser/tests/test_pagetemplatefile.py
2010-01-06 01:31:21 UTC (rev 107725)
+++ Zope/trunk/src/Products/Five/browser/tests/test_pagetemplatefile.py
2010-01-06 01:50:37 UTC (rev 107726)
@@ -37,13 +37,13 @@
from zope.tales.expressions import DeferExpr
from zope.tales.expressions import NotExpr
from zope.tales.expressions import PathExpr
-from zope.tales.expressions import StringExpr
from zope.tales.expressions import Undefs
from zope.tales.pythonexpr import PythonExpr
from zope.contentprovider.tales import TALESProviderExpression
from Products.PageTemplates.DeferExpr import LazyExpr
from Products.PageTemplates.Expressions import TrustedZopePathExpr
from Products.PageTemplates.Expressions import SecureModuleImporter
+from Products.PageTemplates.Expressions import UnicodeAwareStringExpr
vptf = self._makeOne('seagull.pt')
engine = vptf.pt_getEngine()
@@ -51,7 +51,7 @@
self.assertEqual(engine.types['path'], TrustedZopePathExpr)
self.assertEqual(engine.types['exists'], TrustedZopePathExpr)
self.assertEqual(engine.types['nocall'], TrustedZopePathExpr)
-self.assertEqual(engine.types['string'], StringExpr)
+self.assertEqual(engine.types['string'], UnicodeAwareStringExpr)
self.assertEqual(engine.types['python'], PythonExpr)
self.assertEqual(engine.types['not'], NotExpr)
self.assertEqual(engine.types['defer'], DeferExpr)
Modified: Zope/trunk/src/Products/PageTemplates/Expressions.py
===
--- Zope/trunk/src/Products/PageTemplates/Expressions.py2010-01-06
01:31:21 UTC (rev 107725)
+++ Zope/trunk/src/Products/PageTemplates/Expressions.py2010-01-06
01:50:37 UTC (rev 107726)
@@ -372,12 +372,26 @@
return False
return ob1 == ob2
+class UnicodeAwareStringExpr(StringExpr):
+
+def __call__(self, econtext):
+vvals = []
+if isinstance(self._expr, unicode):
+# coerce values through the Unicode Conflict Resolver
+evaluate = econtext.evaluateText
+else:
+evaluate = econtext.evaluate
+for var in self._vars:
+v = evaluate(var)
+vvals.append(v)
+return self._expr % tuple(vvals)
+
def createZopeEngine(zpe=ZopePathExpr):
e = ZopeEngine()
e.iteratorFactory = PathIterator
for pt in zpe._default_type_names:
e.registerType(pt, zpe)
-e.registerType('string', StringExpr)
+e.registerType('string', UnicodeAwareStringExpr)
e.registerType('python', ZRPythonExpr.PythonExpr)
e.registerType('not', NotExpr)
e.registerType('defer', DeferExpr)
Modified: Zope/trunk/src/Products/PageTemplates/tests/testExpressions.py
===
--- Zope/trunk/src/Products/PageTemplates/tests/testExpressions.py
2010-01-06 01:31:21 UTC (rev 107725)
+++ Zope/trunk/src/Products/PageTemplates/tests/testExpressions.py
2010-01-06 01:50:37 UTC (rev 107726)
@@ -25,12 +25,20 @@
__allow_access_to_unprotected_subobjects__ = 1
def __call__(self):
return 'dummy'
+
+management_page_charset = 'iso-8859-15'
class DummyDocumentTemplate:
__allow_access_to_unprotected_subobjects__ = 1
isDocTemp = True
def __call__(self, client=None, REQUEST={}, RESPONSE=None, **kw):
return 'dummy'
+
+def absolute_url(self, relative=0):
+url = 'dummy'
+if not relative:
+url = http://server/; + url
+return url
_DEFAULT_BINDINGS = dict(
Re: [Zope-dev] A summary of Interfaces vs ZCA concepts
We've been through this option recently already. It has been quickly shot down by those who want interfaces to get the new behaviour immediately available in existing interfaces, instead of having to rewrite already existing interfaces to support the new API. Painful memories of a time when we had 2 interface implementations come to mind. Though in this case, with z.c.Interface extending z.i.Interface, we probably wouldn't have so much backward compatibility issues as we had before: the new API would just not be available in non migrated code, and old code could treat z.c.Interfaces just like z.i.Interfaces. On Thu, Dec 17, 2009 at 15:07, Gary Poster gary.pos...@gmail.com wrote: Yeah, I was thinking that too, as a I don't have time to think hard about this little daydream. Actually I believe you would want to subclass InterfaceClass and make your new zope.component.Interface an instance of the new InterfaceClass and specify zope.interface's Interface as something it extends. Then packages in the Zope world would start to use that Interface, I'd guess. I don't know how I feel about it. Gary On Dec 17, 2009, at 11:51 AM, Chris McDonough wrote: I'll throw out the obvious... Why not subclass Interface in zope.component and make the required API additions there? If it were anybody but us thinking about doing this, they'd probably just subclass. - C Martijn Faassen wrote: Wichert Akkerman wrote: [knip] Perhapse LookupError should be a subclass of TypeError. It's a Python built-in. :) Regards, Martijn ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name, default): This method would be called by any attempt to look up an interface attribute that isn't provided by zope.interface itself. For example: IFoo.adapter(bar, default=baz) Would be the almost the same as: getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz) That is unless getInterfaceAttribute(IFoo, 'adapter') returned the passed-in marker which would instruct zope.interface to raise an AttributeError instead. In turn, zope.component could then provide a getInterfaceAttribute() implementation that called: getAdapter(IFoo, interface=IInterfaceMethod, name='adapter') Yes, the first parameter above is the original interface. The IInterfaceMethod is an interface defining __call__(*args, **kw) This idea would also allow one to define named adapters for IInterfaceMethod to, for instance, __call__ or __add__, such that the semantics of IFoo(...) or IFoo + IBar could also be changed. Perhaps entry points could be used to provide getInterfaceAttribute implementations, and if multiple entry points are present, each would be called in turn to attempt to provide the attributes of an interface, but maybe this is too much flexibility... Just an idea... Cheers, Leo On Tue, Dec 15, 2009 at 14:16, Thomas Lotze t...@gocept.com wrote: So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? -- Thomas ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce
Re: [Zope-dev] ZCA proposal
For my 2 cents (not that I think anyone should care): +1 for IFoo.adapt[er](*args, **kw) and IFoo.utility(*kw) -1 for tuple adaptation on 1st arg. Besides losing genericity on tuple adaptation, we risk situations where a class could trigger multi-adaptation by inheriting from tuple. +1 for deprecating unamed default argument. Yes, this is separate from the 1st item above but if in the future we want to expand/fix the IFoo() semantics, we should start deprecating things as early as possible. Besides defalt=something is way more readable and explicitly, especially when you consider the typecasting mindset. Cheers, Leo On Thu, Dec 3, 2009 at 10:00, Martijn Faassen faas...@startifact.com wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. Regards, Martijn ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
I find it rather odd that we're wasting so much time worrying about backward incompatibility when we have a perfect mechanism to introduce backward incompatible changes in a way that allows both flavours to be used by packages in the same application (on a module by module basis just like Martijn would like): * Use a different package name! Yes, I know, zope.component and zope.interface are such clear and nice names, and it'd be a shame to let them go for the sake of a new and better API. But why should we even go down the route of backward incompatibility? We can keep the backward compatibility forever while having zero code duplication by implementing the old API on top of the newer one. It's what we've been doing all these years on zope.app namespace and even on the Zope 2 codebase. It's a tried and true method. It's not like we're changing the core Python language in a way as to correct previous uncorrectable mistakes. It's just a couple of pakages! And to have a little bit more of bike sheds to paint, I'll even suggest the new names: zc.component and zc.interface. We'll even save a couple of bytes on every import. Cheers, Leo On Mon, Nov 30, 2009 at 10:43, Hanno Schlichting ha...@hannosch.eu wrote: On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli optilude+li...@gmail.com wrote: Martijn Faassen wrote: This implies we don't want to release zope.component 4.0 for a long time yet. I think the answer should be never. :) I think never is a rather long time. I'd suggest we think about these changes more in the timeline of years. Looking at Python itself or Zope's own former deprecation policies, it seems that policies where we deprecate / warn about API changes in one release and change behavior it one or two releases after that seem to work. They do rely on their being something like a coherent release of some language / framework / toolkit though. And they rely on these releases being made at an interval of at minimum a year or preferably 18 months (as in Python's case). I think that once we get a ZTK 1.0 release out that promises to be maintained for at least three years, we can start working on a ZTK 2.0 which introduces deprecation warnings about the changed behavior and a 3.0 that will change the default. If released at an interval of 18 months like Python, that puts these changes about 3 years into the future with a lot of time in between to adjust. Given such an approach I think we can indeed change core API's in backwards incompatible ways. Python itself does this all the time, look at Exceptions as new-style classes, new language keywords like with or the massive amount of changes in Python 3. But if we treat zope.component / zope.interface just as two packages of their own, I'd agree that we don't have any way to provide reasonable backwards compatibility and ensure that some packages won't use these straight away. The whole point of the toolkit is to ensure we have a large number of packages that are compatible and tested with each other. Hanno ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - one more ZPublisher event
Wouldn't it be better to just move IPubFailure before the abort? Is there a reason for subscribing to such an event which would required the transaction to be aborted already? I can see the usefulness of the transaction being already doom()ed before this event, but not aborted. On Wed, Nov 11, 2009 at 08:53, Martin Aspeli optilude+li...@gmail.com wrote: Hi, In Zope 2.12 ZPublisher we have a good set of events now, which provide useful hooks for modifying the response before or after publication. However, I'd like to add one more. ;-) Basically, we have IPubFailure, but this is sent *after* transaction.abort() and endInteraction(). This means that it's impossible to read from the ZODB when trying to deal with a failure. I'd like to add an event before that, IPubBeforeAbort, which mirrors IPubBeforeCommit in being sent before the transaction is aborted. I can do this on Zope trunk + 2.12 branch if no-one objects. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - one more ZPublisher event
On Thu, Nov 12, 2009 at 12:29, Martin Aspeli optilude+li...@gmail.com wrote: Leonardo Rochael Almeida wrote: Wouldn't it be better to just move IPubFailure before the abort? [...] I can see the usefulness of the transaction being already doom()ed before this event, but not aborted. There is an IPubSuccess which runs after the transaction is closed. Doing post-processing after closure may be useful to keep transactions shorter and thus reduce the risk of conflict errors. I don't think an extra event will cost us much, so being consistent and granular is probably best. Fair enough. I still suggest doom()ing the transaction before this event. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope closes connection if the client closes the write-end of connection
On Sat, Oct 17, 2009 at 10:30, Lennart Regebro rege...@gmail.com wrote: 2009/10/16 Lennart Regebro rege...@gmail.com: So HTTP seems to contradict itself, typically But from looking at other peoples responses, most interpret the specification that the connection should immediately be closed, so the Zope does the right thing there, and Varnish should be changed. This is apparently the generally accepted interpretation. Of course, it would make even more sense if Zope the immediately stopped the transaction, but i have no idea how THAT would work... - sys.maxint I definitively don't want zope to cancel a long running transaction just because my browser got tired of waiting. At the very least this should be configurable, though I can see a lot of value of being able to toggle this cancel-transaction behaviour per-request. But the default should be off (i.e. the transaction keeps going). Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope closes connection if the client closes the write-end of connection
On Fri, Oct 16, 2009 at 16:36, Tres Seaver tsea...@palladion.com wrote: [...] You might also look at fixing varnish: I don't know of any valid reason for it to be using the half-open connection model to test that an HTTP-based backend is up Going out on a limb here, but I think Varnish might be trying to save on file-descriptors. It could be a while before a backend-server answers and Varnish could have a large number of fds open on any given time while talking to both clients and servers. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/trunk/src/Shared/DC/ZRDB/Connection.py Forward port 105096 to trunk. Missed Globals removal.
Log message for revision 105097: Forward port 105096 to trunk. Missed Globals removal. Changed: U Zope/trunk/src/Shared/DC/ZRDB/Connection.py -=- Modified: Zope/trunk/src/Shared/DC/ZRDB/Connection.py === --- Zope/trunk/src/Shared/DC/ZRDB/Connection.py 2009-10-15 20:00:37 UTC (rev 105096) +++ Zope/trunk/src/Shared/DC/ZRDB/Connection.py 2009-10-15 20:03:56 UTC (rev 105097) @@ -70,7 +70,7 @@ self.edit(title, connection_string, check) def __setstate__(self, state): -Globals.Persistent.__setstate__(self, state) +Persistent.__setstate__(self, state) if self.connection_string: try: self.connect(self.connection_string) except: ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/src/Shared/DC/ZRDB/Connection.py Tres, you missed a spot
Log message for revision 105096: Tres, you missed a spot Changed: U Zope/branches/2.12/src/Shared/DC/ZRDB/Connection.py -=- Modified: Zope/branches/2.12/src/Shared/DC/ZRDB/Connection.py === --- Zope/branches/2.12/src/Shared/DC/ZRDB/Connection.py 2009-10-15 19:47:09 UTC (rev 105095) +++ Zope/branches/2.12/src/Shared/DC/ZRDB/Connection.py 2009-10-15 20:00:37 UTC (rev 105096) @@ -70,7 +70,7 @@ self.edit(title, connection_string, check) def __setstate__(self, state): -Globals.Persistent.__setstate__(self, state) +Persistent.__setstate__(self, state) if self.connection_string: try: self.connect(self.connection_string) except: ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/src/HelpSys/APIHelpTopic.py Fix HelpSys to work with zope.interface.Interface as it did before the deprecated methods of scarecrow Interface.Interface were remo
Log message for revision 105060: Fix HelpSys to work with zope.interface.Interface as it did before the deprecated methods of scarecrow Interface.Interface were removed. Changed: U Zope/branches/2.12/src/HelpSys/APIHelpTopic.py -=- Modified: Zope/branches/2.12/src/HelpSys/APIHelpTopic.py === --- Zope/branches/2.12/src/HelpSys/APIHelpTopic.py 2009-10-14 08:35:10 UTC (rev 105059) +++ Zope/branches/2.12/src/HelpSys/APIHelpTopic.py 2009-10-14 08:54:25 UTC (rev 105060) @@ -48,8 +48,8 @@ if type(v)==types.ClassType: # A class. self.apis.append(APIDoc(v, 0)) -elif (hasattr(v, 'isImplementedByInstancesOf')): -# A scarecrow interface. +elif (hasattr(v, 'implementedBy')): +# A zope.interface.Interface. self.apis.append(APIDoc(v, 1)) elif type(v)==types.FunctionType: # A function ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/src/HelpSys/APIHelpTopic.py Merge 105060 from branch 2.12: Fix HelpSys to work with zope.interface.Interface as it did before the deprecated methods of scarecrow Interf
Log message for revision 105062: Merge 105060 from branch 2.12: Fix HelpSys to work with zope.interface.Interface as it did before the deprecated methods of scarecrow Interface.Interface were removed. Changed: U Zope/trunk/src/HelpSys/APIHelpTopic.py -=- Modified: Zope/trunk/src/HelpSys/APIHelpTopic.py === --- Zope/trunk/src/HelpSys/APIHelpTopic.py 2009-10-14 08:54:58 UTC (rev 105061) +++ Zope/trunk/src/HelpSys/APIHelpTopic.py 2009-10-14 08:57:25 UTC (rev 105062) @@ -48,8 +48,8 @@ if type(v)==types.ClassType: # A class. self.apis.append(APIDoc(v, 0)) -elif (hasattr(v, 'isImplementedByInstancesOf')): -# A scarecrow interface. +elif (hasattr(v, 'implementedBy')): +# A zope.interface.Interface. self.apis.append(APIDoc(v, 1)) elif type(v)==types.FunctionType: # A function ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ revert ZCatalog.getobject() semantics not to mask traversal errors and not to fallback to .resolve_url() when the trav
Log message for revision 71167:
revert ZCatalog.getobject() semantics not to mask traversal errors and not to
fallback to .resolve_url() when the traversal result is None
Changed:
U Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py
U
Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py
2006-11-17 18:32:00 UTC (rev 71166)
+++ Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py
2006-11-17 19:51:12 UTC (rev 71167)
@@ -615,12 +615,7 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
-if obj is None:
-if REQUEST is None:
-REQUEST=self.REQUEST
-obj = self.resolve_url(self.getpath(rid), REQUEST)
-return obj
+return self.aq_parent.unrestrictedTraverse(self.getpath(rid))
def getMetadataForUID(self, uid):
return the correct metadata given the uid, usually the path
Modified:
Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py
===
---
Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 18:32:00 UTC (rev 71166)
+++
Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 19:51:12 UTC (rev 71167)
@@ -177,15 +177,23 @@
def __nonzero__(self):
self.fail(__nonzero__() was called)
+class FakeTraversalError(KeyError):
+fake traversal exception for testing
+
class fakeparent(Implicit):
# fake parent mapping unrestrictedTraverse to
# catalog.resolve_path as simulated by TestZCatalog
def __init__(self, d):
self.d = d
-def unrestrictedTraverse(self, path, default=None):
-return self.d.get(path, default)
+marker = object()
+def unrestrictedTraverse(self, path, default=marker):
+result = self.d.get(path, default)
+if result is self.marker:
+raise FakeTraversalError(path)
+return result
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -283,7 +291,7 @@
self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
def testBooleanEvalOn_refreshCatalog_getobject(self):
-# wrap catalog under the fake parent
+# wrap catalog under the fake parent providing unrestrictedTraverse()
catalog = self._catalog.__of__(fakeparent(self.d))
# replace entries to test refreshCatalog
self.d['0'] = dummyLenFail(0, self.fail)
@@ -292,10 +300,27 @@
catalog.refreshCatalog()
for uid in ('0', '1'):
-rid = self._catalog.getrid(uid)
+rid = catalog.getrid(uid)
# neither should these
catalog.getobject(rid)
+def
test_getobject_doesntMaskTraversalErrorsAndDoesntDelegateTo_resolve_url(self):
+# wrap catalog under the fake parent providing unrestrictedTraverse()
+catalog = self._catalog.__of__(fakeparent(self.d))
+# make resolve_url fail if ZCatalog falls back on it
+def resolve_url(path, REQUEST):
+self.fail(.resolve_url() should not be called by .getobject())
+catalog.resolve_url = resolve_url
+
+# traversal should work at first
+rid0 = catalog.getrid('0')
+# lets set it up so the traversal fails
+del self.d['0']
+self.assertRaises(FakeTraversalError, catalog.getobject, rid0,
REQUEST=object())
+# and if there is a None at the traversal point, that's where it
should return
+self.d['0'] = None
+self.assertEquals(catalog.getobject(rid0), None)
+
class dummy(ExtensionClass.Base):
att1 = 'att1'
att2 = 'att2'
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/Products/ZCatalog/ revert ZCatalog.getobject() semantics not to mask traversal errors and not to fallback to .resolve_url() when the traversal result
Log message for revision 71168:
revert ZCatalog.getobject() semantics not to mask traversal errors and not to
fallback to .resolve_url() when the traversal result is None
Changed:
U Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py
U Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-17
19:51:12 UTC (rev 71167)
+++ Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-17
20:01:22 UTC (rev 71168)
@@ -615,12 +615,7 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
-if obj is None:
-if REQUEST is None:
-REQUEST=self.REQUEST
-obj = self.resolve_url(self.getpath(rid), REQUEST)
-return obj
+return self.aq_parent.unrestrictedTraverse(self.getpath(rid))
def getMetadataForUID(self, uid):
return the correct metadata given the uid, usually the path
Modified: Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
===
--- Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 19:51:12 UTC (rev 71167)
+++ Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 20:01:22 UTC (rev 71168)
@@ -177,15 +177,23 @@
def __nonzero__(self):
self.fail(__nonzero__() was called)
+class FakeTraversalError(KeyError):
+fake traversal exception for testing
+
class fakeparent(Implicit):
# fake parent mapping unrestrictedTraverse to
# catalog.resolve_path as simulated by TestZCatalog
def __init__(self, d):
self.d = d
-def unrestrictedTraverse(self, path, default=None):
-return self.d.get(path, default)
+marker = object()
+def unrestrictedTraverse(self, path, default=marker):
+result = self.d.get(path, default)
+if result is self.marker:
+raise FakeTraversalError(path)
+return result
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -283,7 +291,7 @@
self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
def testBooleanEvalOn_refreshCatalog_getobject(self):
-# wrap catalog under the fake parent
+# wrap catalog under the fake parent providing unrestrictedTraverse()
catalog = self._catalog.__of__(fakeparent(self.d))
# replace entries to test refreshCatalog
self.d['0'] = dummyLenFail(0, self.fail)
@@ -292,10 +300,27 @@
catalog.refreshCatalog()
for uid in ('0', '1'):
-rid = self._catalog.getrid(uid)
+rid = catalog.getrid(uid)
# neither should these
catalog.getobject(rid)
+def
test_getobject_doesntMaskTraversalErrorsAndDoesntDelegateTo_resolve_url(self):
+# wrap catalog under the fake parent providing unrestrictedTraverse()
+catalog = self._catalog.__of__(fakeparent(self.d))
+# make resolve_url fail if ZCatalog falls back on it
+def resolve_url(path, REQUEST):
+self.fail(.resolve_url() should not be called by .getobject())
+catalog.resolve_url = resolve_url
+
+# traversal should work at first
+rid0 = catalog.getrid('0')
+# lets set it up so the traversal fails
+del self.d['0']
+self.assertRaises(FakeTraversalError, catalog.getobject, rid0,
REQUEST=object())
+# and if there is a None at the traversal point, that's where it
should return
+self.d['0'] = None
+self.assertEquals(catalog.getobject(rid0), None)
+
class dummy(ExtensionClass.Base):
att1 = 'att1'
att2 = 'att2'
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/ZCatalog/ revert ZCatalog.getobject() semantics not to mask traversal errors and not to fallback to .resolve_url() when the traversal resul
Log message for revision 71169:
revert ZCatalog.getobject() semantics not to mask traversal errors and not to
fallback to .resolve_url() when the traversal result is None
Changed:
U Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py
U Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-17
20:01:22 UTC (rev 71168)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-17
20:11:22 UTC (rev 71169)
@@ -587,12 +587,7 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
-if obj is None:
-if REQUEST is None:
-REQUEST=self.REQUEST
-obj = self.resolve_url(self.getpath(rid), REQUEST)
-return obj
+return self.aq_parent.unrestrictedTraverse(self.getpath(rid))
def getMetadataForUID(self, uid):
return the correct metadata given the uid, usually the path
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 20:01:22 UTC (rev 71168)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 20:11:22 UTC (rev 71169)
@@ -177,15 +177,23 @@
def __nonzero__(self):
self.fail(__nonzero__() was called)
+class FakeTraversalError(KeyError):
+fake traversal exception for testing
+
class fakeparent(Implicit):
# fake parent mapping unrestrictedTraverse to
# catalog.resolve_path as simulated by TestZCatalog
def __init__(self, d):
self.d = d
-def unrestrictedTraverse(self, path, default=None):
-return self.d.get(path, default)
+marker = object()
+def unrestrictedTraverse(self, path, default=marker):
+result = self.d.get(path, default)
+if result is self.marker:
+raise FakeTraversalError(path)
+return result
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -283,7 +291,7 @@
self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
def testBooleanEvalOn_refreshCatalog_getobject(self):
-# wrap catalog under the fake parent
+# wrap catalog under the fake parent providing unrestrictedTraverse()
catalog = self._catalog.__of__(fakeparent(self.d))
# replace entries to test refreshCatalog
self.d['0'] = dummyLenFail(0, self.fail)
@@ -292,10 +300,27 @@
catalog.refreshCatalog()
for uid in ('0', '1'):
-rid = self._catalog.getrid(uid)
+rid = catalog.getrid(uid)
# neither should these
catalog.getobject(rid)
+def
test_getobject_doesntMaskTraversalErrorsAndDoesntDelegateTo_resolve_url(self):
+# wrap catalog under the fake parent providing unrestrictedTraverse()
+catalog = self._catalog.__of__(fakeparent(self.d))
+# make resolve_url fail if ZCatalog falls back on it
+def resolve_url(path, REQUEST):
+self.fail(.resolve_url() should not be called by .getobject())
+catalog.resolve_url = resolve_url
+
+# traversal should work at first
+rid0 = catalog.getrid('0')
+# lets set it up so the traversal fails
+del self.d['0']
+self.assertRaises(FakeTraversalError, catalog.getobject, rid0,
REQUEST=object())
+# and if there is a None at the traversal point, that's where it
should return
+self.d['0'] = None
+self.assertEquals(catalog.getobject(rid0), None)
+
class dummy(ExtensionClass.Base):
att1 = 'att1'
att2 = 'att2'
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/ZCatalog/ revert ZCatalog.getobject() semantics not to mask traversal errors and not to fallback to .resolve_url() when the traversal result is None
Log message for revision 71170:
revert ZCatalog.getobject() semantics not to mask traversal errors and not to
fallback to .resolve_url() when the traversal result is None
Changed:
U Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py
U Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-17 20:11:22 UTC
(rev 71169)
+++ Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-17 20:17:28 UTC
(rev 71170)
@@ -587,12 +587,7 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
-if obj is None:
-if REQUEST is None:
-REQUEST=self.REQUEST
-obj = self.resolve_url(self.getpath(rid), REQUEST)
-return obj
+return self.aq_parent.unrestrictedTraverse(self.getpath(rid))
def getMetadataForUID(self, uid):
return the correct metadata given the uid, usually the path
Modified: Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 20:11:22 UTC (rev 71169)
+++ Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-17 20:17:28 UTC (rev 71170)
@@ -177,15 +177,23 @@
def __nonzero__(self):
self.fail(__nonzero__() was called)
+class FakeTraversalError(KeyError):
+fake traversal exception for testing
+
class fakeparent(Implicit):
# fake parent mapping unrestrictedTraverse to
# catalog.resolve_path as simulated by TestZCatalog
def __init__(self, d):
self.d = d
-def unrestrictedTraverse(self, path, default=None):
-return self.d.get(path, default)
+marker = object()
+def unrestrictedTraverse(self, path, default=marker):
+result = self.d.get(path, default)
+if result is self.marker:
+raise FakeTraversalError(path)
+return result
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -283,7 +291,7 @@
self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
def testBooleanEvalOn_refreshCatalog_getobject(self):
-# wrap catalog under the fake parent
+# wrap catalog under the fake parent providing unrestrictedTraverse()
catalog = self._catalog.__of__(fakeparent(self.d))
# replace entries to test refreshCatalog
self.d['0'] = dummyLenFail(0, self.fail)
@@ -292,10 +300,27 @@
catalog.refreshCatalog()
for uid in ('0', '1'):
-rid = self._catalog.getrid(uid)
+rid = catalog.getrid(uid)
# neither should these
catalog.getobject(rid)
+def
test_getobject_doesntMaskTraversalErrorsAndDoesntDelegateTo_resolve_url(self):
+# wrap catalog under the fake parent providing unrestrictedTraverse()
+catalog = self._catalog.__of__(fakeparent(self.d))
+# make resolve_url fail if ZCatalog falls back on it
+def resolve_url(path, REQUEST):
+self.fail(.resolve_url() should not be called by .getobject())
+catalog.resolve_url = resolve_url
+
+# traversal should work at first
+rid0 = catalog.getrid('0')
+# lets set it up so the traversal fails
+del self.d['0']
+self.assertRaises(FakeTraversalError, catalog.getobject, rid0,
REQUEST=object())
+# and if there is a None at the traversal point, that's where it
should return
+self.d['0'] = None
+self.assertEquals(catalog.getobject(rid0), None)
+
class dummy(ExtensionClass.Base):
att1 = 'att1'
att2 = 'att2'
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Re: [Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ fix #2235 for real now
Em Sex, 2006-11-17 às 07:48 +, Chris Withers escreveu: Leonardo Rochael Almeida wrote: [] This is the full method before my changes: def getobject(self, rid, REQUEST=None): Return a cataloged object given a 'data_record_id_' obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid)) if not obj: if REQUEST is None: REQUEST=self.REQUEST obj = self.resolve_url(self.getpath(rid), REQUEST) return obj [...] A) Keep my changes, but use a marker object() instead of None for the default parameter of the .unrestrictedTraverse() call. B) Reverse my changes, but also remove the if not obj block, which is buggy whichever way you look at it with the old unrestrictedTraverse call. Which one should it be? I'd go for B. If no one else chimes in today, I'll implement B. ZCatalog .getobject(rid) call will simply call unrestrictedTraverse, ignoring the REQUEST. parameter. I'll add a deprecation warning on the trunk if the REQUEST parameter is passed in. Cheers, Leo -- Leonardo Rochael Almeida Enfold Systems http://www.enfoldsystems.com phone. +1.713.942.2377 Ext 215 fax. +1.832.201.8856 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Upcoming releases: 2.10.1, 2.9.6
Em Sex, 2006-11-17 às 14:20 -0200, Dorneles Treméa escreveu: Hey folks, I am planning to release 2.10.1 and 2.9.6 early next week (likely on TUE). anyone with 5 minutes available to bless my fix for #2191? :-) http://www.zope.org/Collectors/Zope/2191 Looks good enough for me. -- Leonardo Rochael Almeida Enfold Systems http://www.enfoldsystems.com phone. +1.713.942.2377 Ext 215 fax. +1.832.201.8856 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ fix #2235 for real now
Hi Chris, Em Qui, 2006-11-16 às 07:33 +, Chris Withers escreveu: Leonardo Rochael Almeida wrote: @@ -615,8 +615,8 @@ def getobject(self, rid, REQUEST=None): Return a cataloged object given a 'data_record_id_' -obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid)) -if not obj: +obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None) +if obj is None: Please revert this change. You've changed the semantics of this statement and it will now mask errors in traversing to the path. This is bad... I agree with you the semantics have changed, but I argue that they've changed to what they were intended to be in the first place :-) This is the full method before my changes: def getobject(self, rid, REQUEST=None): Return a cataloged object given a 'data_record_id_' obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid)) if not obj: if REQUEST is None: REQUEST=self.REQUEST obj = self.resolve_url(self.getpath(rid), REQUEST) return obj Here it is, after my changes def getobject(self, rid, REQUEST=None): Return a cataloged object given a 'data_record_id_' obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None) if obj is None: if REQUEST is None: REQUEST=self.REQUEST obj = self.resolve_url(self.getpath(rid), REQUEST) return obj Traversing with a default argument will only mask traversal errors, not any other errors that might happen during traversing. If the intent was not to mask any errors at all, even the ones normal to traversal, then the if not obj that was there before would only be triggered in situations where there it was a bug: an object was found but it's got a .__len__ or .__nonzero__ method. In the version with my changes, but with the old unrestrictedTraverse call, the if obj is None would only ever be reached in the pathological situation where the attribute at the end of the path is None. Which means the .resolve_url(self.getpath(rid), REQUEST) would hardly ever be called at all. I'm open to reversing the unrestrictedTraverse call to the old semantics, as soon as we agree what those where, so I propose 2 options and I'll implement whatever this list decides: A) Keep my changes, but use a marker object() instead of None for the default parameter of the .unrestrictedTraverse() call. B) Reverse my changes, but also remove the if not obj block, which is buggy whichever way you look at it with the old unrestrictedTraverse call. Which one should it be? Cheers, Leo -- Leonardo Rochael Almeida Enfold Systems http://www.enfoldsystems.com phone. +1.713.942.2377 Ext 215 fax. +1.832.201.8856 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.9/ fix for #2235: ZCatalog triggering boolean evaluation of objects
Log message for revision 71132:
fix for #2235: ZCatalog triggering boolean evaluation of objects
Changed:
U Zope/branches/2.9/doc/CHANGES.txt
U Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py
U Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/branches/2.9/doc/CHANGES.txt
===
--- Zope/branches/2.9/doc/CHANGES.txt 2006-11-15 08:00:29 UTC (rev 71131)
+++ Zope/branches/2.9/doc/CHANGES.txt 2006-11-15 08:05:34 UTC (rev 71132)
@@ -9,6 +9,11 @@
Bugs fixed
+ - Collector #2235: A number of ZCatalog methods were doing boolean
+evaluation of objects that implemented __len__ instead of checking
+them against None. Replaced a number of if not obj with
+if obj is not None.
+
- Collector #2218: fixed wrong logger argument in OFS/Cache.py
- Collector #2205: fixed wrong logger argument in ZRDB/Connection.py
Modified: Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15
08:00:29 UTC (rev 71131)
+++ Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15
08:05:34 UTC (rev 71132)
@@ -234,7 +234,7 @@
for url in urls:
obj = self.resolve_path(url)
-if not obj and hasattr(self, 'REQUEST'):
+if obj is None and hasattr(self, 'REQUEST'):
obj = self.resolve_url(url, REQUEST)
if obj is not None:
self.catalog_object(obj, url)
@@ -298,7 +298,7 @@
p = paths[i]
obj = self.resolve_path(p)
-if not obj:
+if obj is None:
obj = self.resolve_url(p, self.REQUEST)
if obj is not None:
try:
@@ -615,8 +615,8 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid))
-if not obj:
+obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
+if obj is None:
if REQUEST is None:
REQUEST=self.REQUEST
obj = self.resolve_url(self.getpath(rid), REQUEST)
Modified: Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
===
--- Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-15 08:00:29 UTC (rev 71131)
+++ Zope/branches/2.9/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-15 08:05:34 UTC (rev 71132)
@@ -28,6 +28,7 @@
from AccessControl.SecurityManagement import setSecurityManager
from AccessControl.SecurityManagement import noSecurityManager
from AccessControl import Unauthorized
+from Acquisition import Implicit
from Products.ZCatalog import Vocabulary
from Products.ZCatalog.Catalog import Catalog
from Products.ZCatalog.Catalog import CatalogError
@@ -159,7 +160,32 @@
def __nonzero__(self):
return False
+# make objects with failing __len__ and __nonzero__
+class dummyLenFail(zdummy):
+def __init__(self, num, fail):
+zdummy.__init__(self, num)
+self.fail = fail
+def __len__(self):
+self.fail(__len__() was called)
+
+class dummyNonzeroFail(zdummy):
+def __init__(self, num, fail):
+zdummy.__init__(self, num)
+self.fail = fail
+
+def __nonzero__(self):
+self.fail(__nonzero__() was called)
+
+class fakeparent(Implicit):
+# fake parent mapping unrestrictedTraverse to
+# catalog.resolve_path as simulated by TestZCatalog
+def __init__(self, d):
+self.d = d
+
+def unrestrictedTraverse(self, path, default=None):
+return self.d.get(path, default)
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -246,7 +272,30 @@
result = self._catalog(title='')
self.assertEquals(1, len(result))
+def testBooleanEvalOn_manage_catalogObject(self):
+self.d['11'] = dummyLenFail(11, self.fail)
+self.d['12'] = dummyNonzeroFail(12, self.fail)
+# create a fake response that doesn't bomb on manage_catalogObject()
+class myresponse:
+def redirect(self, url):
+pass
+# this next call should not fail
+self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
+def testBooleanEvalOn_refreshCatalog_getobject(self):
+# wrap catalog under the fake parent
+catalog = self._catalog.__of__(fakeparent(self.d))
+# replace entries to test refreshCatalog
+self.d['0'] = dummyLenFail(0, self.fail)
+self.d['1'] = dummyNonzeroFail(1, self.fail)
+# this next call should not fail
+catalog.refreshCatalog()
+
+
[Zope-Checkins] SVN: Zope/branches/2.9/doc/CHANGES.txt typo in CHANGES.txt
Log message for revision 71133: typo in CHANGES.txt Changed: U Zope/branches/2.9/doc/CHANGES.txt -=- Modified: Zope/branches/2.9/doc/CHANGES.txt === --- Zope/branches/2.9/doc/CHANGES.txt 2006-11-15 08:05:34 UTC (rev 71132) +++ Zope/branches/2.9/doc/CHANGES.txt 2006-11-15 09:06:14 UTC (rev 71133) @@ -12,7 +12,7 @@ - Collector #2235: A number of ZCatalog methods were doing boolean evaluation of objects that implemented __len__ instead of checking them against None. Replaced a number of if not obj with -if obj is not None. +if obj is None. - Collector #2218: fixed wrong logger argument in OFS/Cache.py ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/ fix for #2235: ZCatalog triggering boolean evaluation of objects
Log message for revision 71135:
fix for #2235: ZCatalog triggering boolean evaluation of objects
Changed:
U Zope/branches/2.10/doc/CHANGES.txt
U Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py
U Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/branches/2.10/doc/CHANGES.txt
===
--- Zope/branches/2.10/doc/CHANGES.txt 2006-11-15 09:07:54 UTC (rev 71134)
+++ Zope/branches/2.10/doc/CHANGES.txt 2006-11-15 09:19:33 UTC (rev 71135)
@@ -12,6 +12,11 @@
- Collector #2213: Can't edit old ZopePageTemplate instances.
+ - Collector #2235: A number of ZCatalog methods were doing boolean
+evaluation of objects that implemented __len__ instead of checking
+them against None. Replaced a number of if not obj with
+if obj is None.
+
- Collector #2208: rewriting/setting the 'charset' part of the
content-type HTTP header will be done only for 'text/*'
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15
09:07:54 UTC (rev 71134)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15
09:19:33 UTC (rev 71135)
@@ -221,7 +221,7 @@
for url in urls:
obj = self.resolve_path(url)
-if not obj and hasattr(self, 'REQUEST'):
+if obj is None and hasattr(self, 'REQUEST'):
obj = self.resolve_url(url, REQUEST)
if obj is not None:
self.catalog_object(obj, url)
@@ -289,7 +289,7 @@
p = paths[i]
obj = self.resolve_path(p)
-if not obj:
+if obj is None:
obj = self.resolve_url(p, self.REQUEST)
if obj is not None:
try:
@@ -587,8 +587,8 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid))
-if not obj:
+obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
+if obj is None:
if REQUEST is None:
REQUEST=self.REQUEST
obj = self.resolve_url(self.getpath(rid), REQUEST)
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-15 09:07:54 UTC (rev 71134)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-15 09:19:33 UTC (rev 71135)
@@ -28,6 +28,7 @@
from AccessControl.SecurityManagement import setSecurityManager
from AccessControl.SecurityManagement import noSecurityManager
from AccessControl import Unauthorized
+from Acquisition import Implicit
from Products.ZCatalog import Vocabulary
from Products.ZCatalog.Catalog import Catalog
from Products.ZCatalog.Catalog import CatalogError
@@ -159,7 +160,32 @@
def __nonzero__(self):
return False
+# make objects with failing __len__ and __nonzero__
+class dummyLenFail(zdummy):
+def __init__(self, num, fail):
+zdummy.__init__(self, num)
+self.fail = fail
+def __len__(self):
+self.fail(__len__() was called)
+
+class dummyNonzeroFail(zdummy):
+def __init__(self, num, fail):
+zdummy.__init__(self, num)
+self.fail = fail
+
+def __nonzero__(self):
+self.fail(__nonzero__() was called)
+
+class fakeparent(Implicit):
+# fake parent mapping unrestrictedTraverse to
+# catalog.resolve_path as simulated by TestZCatalog
+def __init__(self, d):
+self.d = d
+
+def unrestrictedTraverse(self, path, default=None):
+return self.d.get(path, default)
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -246,7 +272,30 @@
result = self._catalog(title='')
self.assertEquals(1, len(result))
+def testBooleanEvalOn_manage_catalogObject(self):
+self.d['11'] = dummyLenFail(11, self.fail)
+self.d['12'] = dummyNonzeroFail(12, self.fail)
+# create a fake response that doesn't bomb on manage_catalogObject()
+class myresponse:
+def redirect(self, url):
+pass
+# this next call should not fail
+self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
+def testBooleanEvalOn_refreshCatalog_getobject(self):
+# wrap catalog under the fake parent
+catalog = self._catalog.__of__(fakeparent(self.d))
+# replace entries to test refreshCatalog
+self.d['0'] = dummyLenFail(0, self.fail)
+self.d['1'] = dummyNonzeroFail(1, self.fail)
+# this next
[Zope-Checkins] SVN: Zope/trunk/ fix for #2235: ZCatalog triggering boolean evaluation of objects
Log message for revision 71136:
fix for #2235: ZCatalog triggering boolean evaluation of objects
Changed:
U Zope/trunk/doc/CHANGES.txt
U Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py
U Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
-=-
Modified: Zope/trunk/doc/CHANGES.txt
===
--- Zope/trunk/doc/CHANGES.txt 2006-11-15 09:19:33 UTC (rev 71135)
+++ Zope/trunk/doc/CHANGES.txt 2006-11-15 09:26:18 UTC (rev 71136)
@@ -13,6 +13,11 @@
- Collector #2213: Can't edit old ZopePageTemplate instances.
+ - Collector #2235: A number of ZCatalog methods were doing boolean
+evaluation of objects that implemented __len__ instead of checking
+them against None. Replaced a number of if not obj with
+if obj is None.
+
- reStructuredText/ZReST: setting raw_enabled to 0 for security
reasons
Modified: Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15 09:19:33 UTC
(rev 71135)
+++ Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15 09:26:18 UTC
(rev 71136)
@@ -221,7 +221,7 @@
for url in urls:
obj = self.resolve_path(url)
-if not obj and hasattr(self, 'REQUEST'):
+if obj is None and hasattr(self, 'REQUEST'):
obj = self.resolve_url(url, REQUEST)
if obj is not None:
self.catalog_object(obj, url)
@@ -289,7 +289,7 @@
p = paths[i]
obj = self.resolve_path(p)
-if not obj:
+if obj is None:
obj = self.resolve_url(p, self.REQUEST)
if obj is not None:
try:
@@ -587,8 +587,8 @@
def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'
-obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid))
-if not obj:
+obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
+if obj is None:
if REQUEST is None:
REQUEST=self.REQUEST
obj = self.resolve_url(self.getpath(rid), REQUEST)
Modified: Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-15 09:19:33 UTC (rev 71135)
+++ Zope/trunk/lib/python/Products/ZCatalog/tests/testCatalog.py
2006-11-15 09:26:18 UTC (rev 71136)
@@ -28,6 +28,7 @@
from AccessControl.SecurityManagement import setSecurityManager
from AccessControl.SecurityManagement import noSecurityManager
from AccessControl import Unauthorized
+from Acquisition import Implicit
from Products.ZCatalog import Vocabulary
from Products.ZCatalog.Catalog import Catalog
from Products.ZCatalog.Catalog import CatalogError
@@ -159,7 +160,32 @@
def __nonzero__(self):
return False
+# make objects with failing __len__ and __nonzero__
+class dummyLenFail(zdummy):
+def __init__(self, num, fail):
+zdummy.__init__(self, num)
+self.fail = fail
+def __len__(self):
+self.fail(__len__() was called)
+
+class dummyNonzeroFail(zdummy):
+def __init__(self, num, fail):
+zdummy.__init__(self, num)
+self.fail = fail
+
+def __nonzero__(self):
+self.fail(__nonzero__() was called)
+
+class fakeparent(Implicit):
+# fake parent mapping unrestrictedTraverse to
+# catalog.resolve_path as simulated by TestZCatalog
+def __init__(self, d):
+self.d = d
+
+def unrestrictedTraverse(self, path, default=None):
+return self.d.get(path, default)
+
class TestZCatalog(unittest.TestCase):
def setUp(self):
@@ -246,7 +272,30 @@
result = self._catalog(title='')
self.assertEquals(1, len(result))
+def testBooleanEvalOn_manage_catalogObject(self):
+self.d['11'] = dummyLenFail(11, self.fail)
+self.d['12'] = dummyNonzeroFail(12, self.fail)
+# create a fake response that doesn't bomb on manage_catalogObject()
+class myresponse:
+def redirect(self, url):
+pass
+# this next call should not fail
+self._catalog.manage_catalogObject(None, myresponse(), 'URL1',
urls=('11', '12'))
+def testBooleanEvalOn_refreshCatalog_getobject(self):
+# wrap catalog under the fake parent
+catalog = self._catalog.__of__(fakeparent(self.d))
+# replace entries to test refreshCatalog
+self.d['0'] = dummyLenFail(0, self.fail)
+self.d['1'] = dummyNonzeroFail(1, self.fail)
+# this next call should not fail
+catalog.refreshCatalog()
+
+for uid in ('0', '1'):
+rid = self._catalog.getrid(uid)
+
[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ fix #2235 for real now
Log message for revision 71127: fix #2235 for real now Changed: U Zope/branches/Zope-2_8-branch/doc/CHANGES.txt U Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py U Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py -=- Modified: Zope/branches/Zope-2_8-branch/doc/CHANGES.txt === --- Zope/branches/Zope-2_8-branch/doc/CHANGES.txt 2006-11-15 05:32:07 UTC (rev 71126) +++ Zope/branches/Zope-2_8-branch/doc/CHANGES.txt 2006-11-15 07:48:38 UTC (rev 71127) @@ -8,8 +8,10 @@ Bugs fixed - - Collector #2235: ZCatalog.manage_catalogObject was triggering __len__ -of objects that implement it, like containers. + - Collector #2235: A number of ZCatalog methods were doing boolean +evaluation of objects that implemented __len__ instead of checking +them against None. Replace a number of if not obj with +if obj is not None. - Fix yet another resTructuredText glitch, and add tests (test backported from 2.9, which was not in fact vulnerable). Modified: Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py === --- Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15 05:32:07 UTC (rev 71126) +++ Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/ZCatalog.py 2006-11-15 07:48:38 UTC (rev 71127) @@ -232,7 +232,7 @@ for url in urls: obj = self.resolve_path(url) -if obj is not None: +if obj is None: obj = self.resolve_url(url, REQUEST) if obj is not None: self.catalog_object(obj, url) @@ -297,7 +297,7 @@ p = paths[i] obj = self.resolve_path(p) -if not obj and hasattr(self, 'REQUEST'): +if obj is None and hasattr(self, 'REQUEST'): obj = self.resolve_url(p, self.REQUEST) if obj is not None: try: @@ -615,8 +615,8 @@ def getobject(self, rid, REQUEST=None): Return a cataloged object given a 'data_record_id_' -obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid)) -if not obj: +obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None) +if obj is None: if REQUEST is None: REQUEST=self.REQUEST obj = self.resolve_url(self.getpath(rid), REQUEST) Modified: Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py === --- Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py 2006-11-15 05:32:07 UTC (rev 71126) +++ Zope/branches/Zope-2_8-branch/lib/python/Products/ZCatalog/tests/testCatalog.py 2006-11-15 07:48:38 UTC (rev 71127) @@ -28,6 +28,7 @@ from AccessControl.SecurityManagement import setSecurityManager from AccessControl.SecurityManagement import noSecurityManager from AccessControl import Unauthorized +from Acquisition import Implicit from Products.ZCatalog import Vocabulary from Products.ZCatalog.Catalog import Catalog from Products.ZCatalog.Catalog import CatalogError @@ -159,7 +160,32 @@ def __nonzero__(self): return False +# make objects with failing __len__ and __nonzero__ +class dummyLenFail(zdummy): +def __init__(self, num, fail): +zdummy.__init__(self, num) +self.fail = fail +def __len__(self): +self.fail(__len__() was called) + +class dummyNonzeroFail(zdummy): +def __init__(self, num, fail): +zdummy.__init__(self, num) +self.fail = fail + +def __nonzero__(self): +self.fail(__nonzero__() was called) + +class fakeparent(Implicit): +# fake parent mapping unrestrictedTraverse to +# catalog.resolve_path as simulated by TestZCatalog +def __init__(self, d): +self.d = d + +def unrestrictedTraverse(self, path, default=None): +return self.d.get(path, default) + class TestZCatalog(unittest.TestCase): def setUp(self): @@ -246,28 +272,30 @@ result = self._catalog(title='') self.assertEquals(1, len(result)) -def test_manage_catalogObject_does_not_trigger_boolean_eval(self): -# make objects with __len__ and __nonzero__ -class mydummy1: -def __init__(self, fail): -self.fail = fail -def __len__(self): -self.fail(__len__() was called) -class mydummy2: -def __init__(self, fail): -self.fail = fail -def __nonzero__(self): -self.fail(__nonzero__() was called) -# store them to be found by the catalog -self.d['0'] = mydummy1(self.fail) -
Re: [Zope-dev] Branches finished for merging.
Em Qua, 2006-04-26 às 19:14 +0200, Lennart Regebro escreveu: I have (at least) two branches that will be merged before The Big Freeze on monday, if all goes well, and unless somebody has any very serious objections. 1. easter-sprint_traversal-refactor [...] 2. regebro-wsgi_refactor +1 to merging both branches I also recommend that we deprecate both __bobo_traverse__ and __browser_default__, but perhaps with a longer derecation period that usual, since this are very basic techniques used in many products. Please discuss. :) +1 to deprecation and to longer period for this case. -- Leonardo Rochael Almeida Enfold Systems http://www.enfoldsystems.com phone. +1.713.942.2377 Ext 215 fax. +1.832.201.8856 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Strange traceback or Error in the traceback ?
Hi,
Em Seg, 2006-01-16 às 16:20 +0100, Godefroid Chapelle escreveu:
Hi,
While seaching for objects of all types containing some text through the
ZMI find tab, I got the traceback hereunder. (Zope 2.7.8-final on
windows)
Traceback (innermost last):
[...]
Module OFS.Image, line 425, in PrincipiaSearchSource
AttributeError: content_typestartswith
I went to the code and found the following :
[...]
if self.content_type.startswith('text/'):
[...]
IOW, the traceback is really strange.
Anybody with a clue ?
I've seen this happen a few times before. In your case, content_type is
probably a standard python function (or method). When an unknown
attribute is looked up in a std python function like that, somehow you
get an AttributeError with the name of the function and the looked up
attribute concatenated, instead of separated by a dot (or more commonly,
instead of the attribute name alone).
Don't know if this is a bad interaction between
ExtensionClass/AttributeError and python, or a python bug.
Cheers, Leo
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] What use cases are driving make install from a checkout?
Just as a data point. A lot of autoconf projects (the ones that made ./configure; make; make install famous) don't just run like that from a checkout, but they are never more than 2 steps away from that. The process for a checkout is usually more like ./autoconf; ./automake; ./configure; make; make install My point is: I don't think there's anything wrong in the install procedure being different between the checkout and the tarball, but it should never take more than a couple of fixed (and documented) steps to convert a checkout to a tarball-equivalent environment, where ./configure; make; make install would work. Cheers, Leo. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: PermissionGeddon
Hi all, Em Dom, 2005-11-27 às 21:26 +0100, Florent Guillaume escreveu: Dieter Maurer wrote: The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. [...] Several Folder like classes are likely to overwrite _setObject and _delObject. Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Maybe. But on the other hand I'd rather not have object manager code slowed down and uglified to suit the negligibly small number of classes that are in this case, and that can be trivialy upgraded in a forward-compatible manner. Not gathering crust is a nice an laudable goal, but so is keep backward compatibility. I humbly suggest that the workaround code on ObjectManager be created with a deprecation warning whenever it's triggered, declaring that the backward compatibility will go away in, say, version 2.11, when it won't be uglified and slowed down anymore. You are, in essence, changing the API. IMHO this should take the same deprecation treatment as everything else. Cheers, Leo. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: PermissionGeddon
Hi Florent Em Ter, 2005-11-29 às 15:32 +0100, Florent Guillaume escreveu: [...] I'm a bit peeved though at the lack of willingness from the few people that have reimplemented their version of _setObject/_delObject (which could be considered private APIs, seeing that they're prefixed with an underscore) to just modify their code for forward compatibility and be done with it, but instead have us embark in a year-long deprecation strategy. This is supposed to be open source, can't we be reactive to change in such situation? Are folks really going to ship their framework code with _setObject unmodified from the current version when they ship it for Five 1.2 or Zope 2.9? They probably will change it, people don't like their code to generate deprecation warnings. But the greatest beneficiaries of the deprecation strategy are not the framework builders, but the users. Suppose a Zope change breaks, say, Plone (to pick two arbitrary examples :-). This means, that in order to upgrade to the next Zope version, I need to upgrade Plone first. If Plone, on the other hand, depends on Zope features that are only available in the newer Zope version, I'm forced to upgrade both layers of my running site simultaneously, making it much more expensive to calculate the migration overhead and procedures. I don't want to start a discussion about whose responsability is to keep compatibility with what software, but I, for one, prefer to upgrade the lower layers of my solutions before the upper layers if possible: Python before Zope, Zope before Plone, Linux kernel before glibc. This is not always possible, and there are loads of counter-examples, but if we can avoid forcing the poor user to upgrade more than one piece of software at a time, I think this is something we should try to achieve. Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Username/userid separation
Em Qui, 2005-08-04 às 08:39 +0100, Jens Vagelpohl escreveu:
On 4 Aug 2005, at 01:01, Leonardo Rochael Almeida wrote:
Hi,
I've started the lra-userid_username_separation-branch (from
Zope-2_8-branch to start from a stable point) in order to implement
proper userid/username separation in Zope.
Chris McDonough did most of that for Zope 2.7 already a long long
time ago. There might be cleanups needed here and there, but for all
practical purposes the separation exists and works. The standard user
folder implementation doesn't support it AFAIK. Where specifically do
you see it not work?
AFAICS, in AccessControl/dtml/owner.dtml, the owner string that is
rendered to the browser comes from Owned.owner_info() in
AccessControl/Owned.py, which comes, untranslated, from
Owned.getOwnerTuple(), which retrieves that value that is set from
Owned.changeOwnership(), which calls ownerInfo() which gets the path to
the user folder and user.getId(), as it should since we are assuming
that .getId() is the immutable and potentially not-displayable
identifier for the user that comes from the user source.
What I'm proposing is to change owner.dtml (with the eventual help of
owner_info()) to get the username equivalent to that userid and display
that instead.
Also, in AccessControl/listLocalRoles.dtml and editLocalRoles.dtml, the
usernames that are rendered from users that already have local roles are
the keys from the RoleManager.__ac_local_roles__ attribute from
AccessControl/Role.py.
These keys eventually come from RoleManager.get_valid_userids(), which
calls acl_users.user_names() for all acl_users in it's acquisition path.
In the default Zope user folder implementation, .user_names() call
getUserNames() which is supposed to list usernames, not userids, which
means we've been storing usernames in __ac_local_roles__ all this time.
This could break if the username for a certain acl_users implementation
changes, specially since User.getRolesInContext() looks up
__ac_local_roles__ with self.getId() and not self.getUserName() in
AccesControl/User.py.
(Actually, isn't it odd that the local roles management is not using the
same approach of owner tuples like Owned.py does?)
I propose that we look up the userid for the username in
RoleManager.manage_{add,set,del}LocalRoles() and change the signature of
these methods to mention username instead of userid.
This might leave us with a slight window for mismatches if the username
for a userid changes between selecting the user in the listLocalRoles
screen and actually setting it after the editLocalRoles screen, but at
least we avoid having to make sure binary userids are correctly quoted
thru all the HTML and URL roundtrips.
What do you guys think?
I've been using it for the LDAPUserFolder for ages where you can
specify different attributes for the ID and the login, and change the
login value at will. And, like Tino mentioned, PAS uses it as well.
Yes, Enfold is aware of PAS, we've been doing the Plone integration for
it and we intend to use it for this particular project for which I need
the changes I mentioned above.
Cheers, Leo
--
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems - http://www.enfoldsystems.com/
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Username/userid separation
Em Qui, 2005-08-04 às 16:20 -0300, Leonardo Rochael Almeida escreveu:
I propose that we look up the userid for the username in
RoleManager.manage_{add,set,del}LocalRoles() and change the signature of
these methods to mention username instead of userid.
And we also need to change RoleManager.get_local_roles() to lookup
usernames for the stored userids.
But this leaves us with another interesting problem: in what user folder
should we be looking up these ids? Theoretically, in all of them,
like .list_valid_usernames() does, but this might bring some different
interactions between local roles set for a username that exists in 2 or
more user folders in the current acquisition path.
The definitive fix for this would involve storing the (userid, acl_users
path) tuple in the local roles information after all, and changing
User.localRolesInContext() accordingly, but this brings a host of
backward compatibility issues which my suggestions above make some
effort to avoid, I believe.
Cheers,
--
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems - http://www.enfoldsystems.com/
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Username/userid separation
Hi, I've started the lra-userid_username_separation-branch (from Zope-2_8-branch to start from a stable point) in order to implement proper userid/username separation in Zope. I don't intend to change the default user folder implementation, just the ZMI interface for owner and local roles so that they keep using userid for storage like they currently do but use usernames for display (specifically acl_users.getUserById(id).getUserName()). The intent is to never leak the userid to the ZMI (except for url query strings and such), and to never store the username persistently. The motivating usecase is an LDAP (eDirectory) authenticated system where the username for a user can change, but not the internal ID (a string). This will also help ActiveDirectory integration, which also has an internal ID to reference users. I remember there being a discussion about this in the list archives, but a Google search didn't help much. Are there any other projects in this area that I should colaborate with instead of duplicating efforts? Are there any considerations I should be aware of? Is the Proposals wiki pages still used for this kind of change? Cheers, Leo -- Leonardo Rochael Almeida [EMAIL PROTECTED] Enfold Systems ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RAMcache and container vs. context
Sorry for comming late into the fray :-)
Em Qui, 2005-04-21 às 19:46 -0400, Paul Winkler escreveu:
On Fri, Apr 22, 2005 at 12:27:18AM +0200, Stefan H. Holek wrote:
Note that aq_parent() gives you the URL parent, not the container. I
see no way around that as the return value of a script may well depend
on its context.
Yes, it may, agreed. Thanks much for pointing out the relevant
code, at least now I understand what's happening.
But I still would like to argue against this behavior:
There *is* an easy alternative, and that's to put one or more
of the many location-related request variables into the
cache manager's configuration.
This alternative won't help you when:
* the pythonscript is sensitive to the context AND
* it is called w/ 2 or more different contexts on the same request
An artificial example I can come up w/ from the top of my head:
Suppose you have a folder w/ an index_html that displays information
about it's subfolders that is calculated by an expensive script and you
want to cache the results of this script, you'd go:
ul
li tal:repeat=subfolder python: here.objectValues('Folder')
Folder span tal:content=subfolder/title_or_id contains
span tal:content=subfolder/expensively_calculate_shruberries
shruberries.
/li
/ul
Then you'd go and RAMCache expensively_calculate_shruberries
But if we implement the change you're suggesting, then this page would
list the same number of shruberries of the first subfolder for all of
them.
-1 from me
For a related annoyance, see:
http://www.zope.org/Collectors/CMF/343
This annoyance is indeed related, but the proper fix is for
FSPythonScript to have a ZCacheable_manage page that takes into account
the fact that it's usually part of a portal_skins setup and deal with
it. Alternativelly, portal_skins should provide the functionality of
expiring RAMCached subitems.
--
Leonardo Rochael Almeida [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Re: Question about procedures
Em Ter, 2005-03-29 às 17:21 +0200, Florent Guillaume escreveu: martin f krafft [EMAIL PROTECTED] wrote: also sprach Florent Guillaume [EMAIL PROTECTED] [2005.03.24.1814 +0100]: -if RESPONSE is not None: +if RESPONSE is not None and ob: You should check 'and ob is not None' too. ... but ob is false when it is None, no? Yes but comparing to None is faster, and in some cases (REQUEST for instance), much much faster, than checking the boolean value. And not every False object is None. A custom object could implement __len__() and be considered false if it's empty, or it could implement __nonzero__() and be considered false even when you want to return it. Cheers, Leo -- Leonardo Rochael Almeida [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZConfig issue: products and container-class
Hi, I found a problematic corner case in the interaction between two zconfig directives: If I set the products directive to a value other than the standard ones (SOFTWARE_HOME/Products or INSTANCE_HOME/Products) AND set the container-class directive of the zodb_db section to a class that is only available inside the alternate products directory specified above, then Zope completely fails to start-up with a configuration error. Reproducing this error is simple. Just set the products directive to, say, $INSTANCE/../Products; put, say, CMF or Plone in there; add another zodb_db section, for instance: zodb_db mounttest filestorage path $INSTANCE/var/mounttest.fs /filestorage mount-point /mounttest container-class Products.CMFPlone.PloneFolder.PloneFolder /zodb_db Change the container-class directive to a class that only exists in ../Products (like Products.CMFPlone.PloneFolder.PloneFolder or Products.CMFCore.PortalFolder.PortalFolder). Finally, try to startup Zope. It will fail with something like: Error: The object named by Products.CMFPlone.PloneFolder.PloneFolder could not be imported (line 862 in file:///home/leo/opt/enfold/etc/zope.conf) For help, use /opt/zopes/Zope-2.7.2/lib/python/Zope/Startup/run.py -h If you comment out the new zodb_db section, Zope starts up fine, and CMF and Plone work ok, proving that the produtcts directive work on it's own. If instead of commenting out the new zodb_db section, you just move your products back to the standard $INSTANCE_HOME/Products location, Zope also starts up ok, proving that the container-class directive works (or at least doesn't keep Zope from starting up). I'm just mentioning this here before filing a collector entry to see if I'm not forgetting something obvious or if others have found the same behaviour. This behaviour is problematic for Windows users with, say, multiprocessor machines, who want to maintain a consistent setup between various ZEO clients, as this forces them to copy products between instances instead of keeping them in a shared location. It's obvious that the container-class directive is being evaluated much earlier than the products directive. Without delving further into the code, it looks like the container-class directive has an error checking built right into the directive type that tries to import the assigned class, while the products direcive will only be made effective AFTER all ZConfig configuration has been processed... Any pointers? Should this go right into the collector? Cheers, Leo -- Leonardo Rochael Almeida [EMAIL PROTECTED] Enfold Systems - http://www.enfolsystems.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZConfig issue: products and container-class
Em Seg, 2005-02-14 às 13:36 -0500, Fred Drake escreveu: On Mon, 14 Feb 2005 15:22:38 -0200, Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: It's obvious that the container-class directive is being evaluated much earlier than the products directive. Without delving further into the code, it looks like the container-class directive has an error checking built right into the directive type that tries to import the assigned class, while the products direcive will only be made effective AFTER all ZConfig configuration has been processed... This is a known limitation. Should I bother with the collector entry or is it a known limitation no one is going to bother with? :-) You can avoid it by using the PYTHONPATH environment variable instead. And it must really be done in the environment, instead of with the path directive, as that is also evaluated too late in the process... Cheers, Leo -- Leonardo Rochael Almeida [EMAIL PROTECTED] Enfold Systems - http://www.enfolsystems.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files
Em Ter, 2004-10-12 às 00:23, Kapil Thangavelu escreveu: i believe you were referring to http://freedesktop.org/Software/shared-mime-info spec http://freedesktop.org/Standards/shared-mime-info-spec its a system wide shared mime database for use by applications (ie. both gnome and kde). apparently no python bindings. Actually, the last url above lists a certain ROX-Lib: http://rox.sourceforge.net/phpwiki/index.php/ROX-Lib It's pure Python and suports a lot of stuff besides mime, but seems to require gtk, which could be a problem for people wanting to maintain slim servers free of any X Window System client dependencies. It's certainly too heavy a dependency for Zope :-) Cheers, Leo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] using VirtualHostMonster in a ZPublisher python module?
Em Ter, 2004-09-21 às 12:17, Royce escreveu: Was hoping to hear of a way to insert a VHM into my zpublisher app object tree or something. Could just hack in hardwired cleanup for URL and BASE but that seems ugly. The code in VHM is really not that complicated. I recommend you read it so that you understand how to change your application to emulate or integrate it. Basically it hooks itself up into __bobo_traverse__ so that it gets called when the request comes in, before all objects in the path (after the root) are looked up. When called, VHM alters the request information (server and path, and as a consequence BASE* and URL*) which has the consequence of changing what objects are looked up to handle the request (i.e. no need for objects called VirtualHostBase or VirtualHostRoot). This is done thru Request methods that where created exactly for this purpose: .setServerURL() and .setVirtualRoot() Documentation for those can be found in the Zope Online Help and other places. Cheers, Leo -- Leonardo Rochael Almeida [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Patch: let non-seekable streams be input for ZPublisher (updated)
Em Qua, 2004-08-18 às 12:22, Ames Andreas (MPA/DF) escreveu: [...] Questions: - Is this the right forum/place to send patches to? This is the right forum to discuss the patches, and to send them for evaluation if it's a small one, like yours. The best place to actually send patches to is as attachment in a bug report in the Zope bug collector. - Is there any chance that this could be applied to Zope's mainline? (If not I will proceed with a local disk buffering scheme in the long term.) Yes, if you file a feature request on the bug collector, which can be found at: http://collector.zope.org/Zope Cheers, Leo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Fwd: Re: [Zope-dev] Referencial Integrity in ZCatalogs]
Forgot to Cc: zope-dev -Mensagem encaminhada- From: Leonardo Rochael Almeida [EMAIL PROTECTED] To: Santi Camps [EMAIL PROTECTED] Subject: Re: [Zope-dev] Referencial Integrity in ZCatalogs Date: Mon, 02 Aug 2004 17:05:53 -0300 I would suggest you take a look at mxmRelations, however Zope.org workflow is keeping it out of reach, and I couldn't find it on MaxM's own site. The URL for it would be: http://www.zope.org/Members/maxm/products/mxmRelations but right now it requires a login. If any kind soul from the Zope web team could release it, or if MaxM could post it somewhere else, that would be very nice. Cheers, Leo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-dev list policies
+1 for member-only posting On Wed, 2004-06-16 at 22:24, Tim Peters wrote: Over on the zope and zope-dev lists, there's currently agitation to make them members-only mailing lists. The point is that spam could not get thru then (unless posted by a member). What would zodb-dev members like? [...] -- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] bug day?
This next Friday (25th) is the last friday of the month. Are we going to have a bugday? Cheers, Leo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope-dev list policies
On Mon, 2004-06-21 at 11:59, Casey Duncan wrote: -1 on changing the list policy. I read and post to all of the public lists through Gmane, which won't work if the policy is changed. I rarely see spam get through list either (unless Gmane is filtering it all out for me), so I fail to see the problem from that point of view. -Casey On Wed, 16 Jun 2004 21:24:07 -0400 Tim Peters [EMAIL PROTECTED] wrote: Over on the zope and zope-dev lists, there's currently agitation to make them members-only mailing lists. The point is that spam could not get thru then (unless posted by a member). What would zodb-dev members like? Posting by a list member would not be affected, unless you attempted to send a message from an email account other than one you subscribed with. In the latter case, your message would be bounced back to you. You could worm around that by subscribing to zodb-dev with that address too, then going to your list membership page on the web and checking the box to suspend email delivery on that account. Then you could post using that account too, but wouldn't also get zodb-dev email on that account. I'm the list admin for zodb-dev, and don't have a preference. If you do, and it's strong enough to scream it, shout. The loudest screamer will winwink. By default, I won't change the current policy (anyone can post here, member or not). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CatalogBrains since Zope2.7.1b1
On Wed, 16 Jun 2004 11:16:55 +0200 Eric Brun [EMAIL PROTECTED] wrote: Hi, I have a problem with 'getObject' method of CatalogBrains class on Zope271b1 : it's return None. But with a Zope2.7.0 my object is correctly find and returned. The permissions are right. Em Qua, 2004-06-16 às 11:28, Casey Duncan escreveu: getObject was refactored recently and its security was increased. It uses restrictedTraverse() now, which means that you need access to all of the enclosing folders as well as the object. Before, no security checking was performed by getObject. I suspect you do not have access to one of the containing folders. I certainly hope he'd get a permission error instead of silent 'None' for '.getObject()' in this case or I'd consider it a bug :-) Cheers, Leo -- Leonardo Rochael Almeida [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote: From: Ken Manheimer [EMAIL PROTECTED] All the actions are verbs, won't fix is not a verb. Can you suggest a verb the more clearly indicates the result is won't fix? Tough one... Live with Ignore Keep this bug as is Zenify Featurize (as in This is not a bug, it's a feature) Shove under carpet Forget Procrastinate Pretend to be deaf How about Refuse to fix? Cheers, leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
