Zope-Dev October 2005

zope-dev@zope.dev

23 participants
42 discussions

New testrunner on the Zope 2 trunk.
by Jim Fulton 07 Dec '05

07 Dec '05

I just checked in a new test runner on the trunk. It is mostly backward compatible with the old test runner. You can get help on the test runner by running it with -h. There is more extensive documentation in lib/python/zope/testing/testrunner.txt. Note that the new test runner complains if test_suite functions don't return test suites. There is a zope.i18n test suite that it currently complains about. Unfortunately, I can't just fix this because it is an svn:external and it will be too painful to create a tag with the necessary fix in the short term. I expect we will be integrating a newer version of Zope 3 later in the week and we'll take care of this then. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 11

RFC: product initialization cleanup and improvements
by yuppie 30 Nov '05

30 Nov '05

Hi! Working on the five:registerClass directive for Five 1.2 and Zope 2.9 I had a closer look at the product initialization code. I propose the following modifications for the dicts in Products.meta_types (set by registerClass): 1.) 'action' key: ----------------- I'd like to give empty 'action' values a special meaning: The meta_type is not visible in the add drop down in the ZMI. The five:registerClass directive allows to set empty 'action' values. This would resolve http://www.zope.org/Collectors/Zope/1885 . Filtering out meta_types with empty 'action' values is a two line change in main.dtml. I'd like to make that change also on the 2.8 branch to enable that feature for 2.8.5 with Five 1.2. 2.) 'interfaces' key: --------------------- Does currently only contain oldstyle interfaces. The code in OFS.ObjectManager that uses that key works also with z3 interfaces. I'd like to add z3 interfaces to the value of that key. That would e.g. allow to set only new style interfaces on catalog index classes. 3.) 'product' key: ------------------ AFAICS it isn't used in Zope itself. I'd like to add a note that it might be removed in a future version. 4.) related cleanup: -------------------- Application.install_product has some backwards compatibility code for products that have initialization code outside the 'initialize' method of their __init__.py. This is deprecated at least for 5 years. I'd like to add explicit deprecation warnings on the 2.8 branch and to remove that code for Zope 2.9. This isn't much work, it can all be done in time for the Zope 2.9 beta. Any feedback is welcome. If there are no objections, I'll make the changes as proposed. Cheers, Yuppie

3 7

Reminder: feature freeze November 1.
by Jim Fulton 14 Nov '05

14 Nov '05

This is a reminder that there will be a feature freeze for the December Zope releases on November 1. No new features for the November releases should be added after October 31. The Zope trunks should be stable and ready for a beta release on November 1. We are committed to time-based releases. This means we need to be very disciplined about deadlines. If a cool new feature isn't quite ready before November 1, then it could be be included in the June release, for which the feature freeze will be May 1. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

8 36

differences in PropertyManager._setPropValue
by Victor Safronovich 03 Nov '05

03 Nov '05

Hello zope-dev! I have a question about PropertyManager._setPropValue in 2.6 and its changed version in 2.7-2.8. I found this revision http://svn.zope.org/Zope/trunk/lib/python/OFS/PropertyManager.py?rev=24349&… Why in this method added conversion to the tuple for all the lists? May be better check for 'lines','tokens' property type? I have a properties of type "list", and i expect that getProperty returns the list type. This works in Zope 2.6, but broken in 2.7-2.8 -- Best regards, Victor Safronovich NauMen.NauDoc.SoftwareDeveloper http://www.naumen.ru

2 3

Maintenance cycles for Zope 2.X branches
by Andreas Jung 02 Nov '05

02 Nov '05

Hi, because of the fact that we are switching to a time-based release cycle for Zope 2 and Zope 3. I would like to discuss how deal with the maintenance of older branches. My idea is to support branches for one year from now on. Zope 2.7 should be maintained until the end of this year, Zope 2.8 until the release of Zope 2.10 in June 2006, Zope 2.9 until the release of Zope 2.11 in December 2006. In case of severe bugs and security problems we can think of making releases for deprecated Zope versions. We could extend the maintenance period for releases if there are some volunteers to take over the responsibility for older branches (isn't there a maintainer for the Linux 2.0 kernel? :-)) From the maintenance point of view it just a nightmare (and it takes a lot of time) to have an overview over more than two or three branches. What do you think? Andreas

3 2

[Proposal] RFC2396 compatible traversal parameters
by Dieter Maurer 01 Nov '05

01 Nov '05

Title: RFC2396 compatible traversal parameters Version: 1.0 Last-Modified: 2005/10/23 Author: Dieter Maurer <dieter(a)handshake.de> Content-Type: text/x-rst Created: 23-October-2005 Abstract ======== RFC2396 defines the overall uri structure. Hierachical uri schemes have a path component consisting of a sequence of path segments. Each path segment consists of a name and optionally a sequence of parameters separated by ``;``. This proposal describes how Zope's publishing component can be enhanced to support path segment parameters, herein called traversal parameters. Rationale ========= There are some important use cases that require information to be kept across successive requests. The most prominent ones are maintaining the session id as well as skin and language selection. We recently met more special ones: keeping tab activation and information about the authentication domain (for remote login). The currently available solutions store this information in: - the session - a cookie - the URL Session and cookie storage have the disadvantages that they do not play well with the browser's history function and that they can seriously confuse caching (mittigated a bit by appropriate 'vary' cache controls, but not solved). Furthermore, cookies might not be available for security reasons. URL storage does not suffer these disadvantages but currently requires the introduction of artificial path segments for the additional information and difficult traversal magic to prevent the artificial segments from interfering with the traversal process. Traversal parameters can solve this much more naturally than artificial path segments. Zope currently does not support traversal parameters. Usage types =========== Traversal parameters can have two kinds of uses: - controlling the traversal process itself - providing information for the whole request Skin selection belongs for example to the first kind, tab activation to the second one; language selection may belong to either of them. While it seems most natural to attach information for the whole request to the last path segment, it is much more practical to use some path segment further to the front as this information might be used automatically (without explicit URL construction) by relative uri references. Risks ===== Support for traversal parameters controlling the traversal process itself will inevitably require deeper changes in Zope's traversal implementation. As this implementation is already quite complex and supports many use cases, the new extension might break some of them. I will outline the special risks in the solution part. There might be clients not implementing RFC 2396. Such clients might support parameters only at the path end and view everything after the first ``;`` as part of the parameters. Such clients might resolve relative uri references incorrectly in the presence of traversal parameters. Proposed solution ================= The solution modifies Zope's ``ZPublisher.BaseRequest.BaseRequest.traverse``. Currently, the ``path`` argument is split into a sequence of names, maintained reversed in the ``TraversalRequestNameStack``. The solution splits it into a sequence of pairs, consisting of the name and the sequence of parameters. ``TraversalRequestNameStack`` will contain the name only when the parameter sequence is empty but the pair, otherwise. Usually, this will allow traversal magic (modification of ``TraversalRequestNameStack`` to change the traversal process) to continue to work as previously unless it hits a pair when it expects a name only. Such (hopefully rare) cases will break. When the traversal process has located a subobject, it checks whether it has a ``__traversal_parameter_process_hook__``. If so, it calls it with ``request`` and the parameter list as arguments. The method may change the list which will affect the parameters added to the constructed (URL) path segment. The traversal will maintain the parameters for the current step in ``TraversalRequestStepParameterList`` to make them available for ``__bobo_traverse__``. An aware ``__bobo_traverse__`` implementation might change this list affecting the parameters seen in further processing. To support parameters destined to the complete request (rather than individual traversal steps), all found parameters are collected in ``TraversalRequestCollectedParameterList``. Individual steps that want to modify the collected parameters can assign a new list to ``TraversalRequestStepCollectParameterList``. The original value is a reference to ``TraversalRequestStepParameterList``. Thus, if it is changed in place, this other list changes as well. For an application, it is difficult to work with parameter lists. Therefore, ``BaseRequest`` gets the new method ``dictifyTraversalParameters``. It takes a parameter list as argument and returns a parameter dictionary. It performs the same conversions and assemblies as ``ZPublisher.HTTPRequest.HTTPRequest.processInputs``. To avoid code duplication, ``processInputs`` is refactored. After traversal, the request gets a lazy key ``TraversalRequestCollectedParameterDict``. It makes the collected traversal parameters available as a dictionary. ``BaseRequest`` gets a new method ``physicalPathToURL`` (that of ``HTTPRequest`` is modified accordingly). It checks whether an object on the path defines a ``__traversal_parameter_creation_hook__``. If so, it is called with the request as argument and can determine the path segment corresponding to this object. This allows ``absolute_url`` and friends to add request parameters to created URLs. There remain some open questions with respect to virtual hosting. I prefer that the URL parts corresponding to the virtual host cannot be modified by traversal parameters during URL construction. -- Dieter

3 3

Memory Leak Question
by Dan Pozmanter 01 Nov '05

01 Nov '05

Ahoy, I was poking around in _Acquisition.c, and noticed my memory usage spiked. Returning to the vanilla code (2.8.2-final), I noticed the same spike (just less pronounced). (If you refresh the page a few gazillion times this pops up). I would not categorize this as an actual bug report (I'd like to test more rigorously with a script to verify a leak), but after reading the note on Changes for 2.8.x in the to do section, I was curious: Is this a known issue? If so, has there been any headway, and can I be of any assistance in resolving it? _______________ Daniel Pozmanter Siteworx, Inc. 703-520-1550 x209 "Festina Lente" - Gaius Julius

2 1

[Zope2.9] Schedule
by Andreas Jung 31 Oct '05

31 Oct '05

Hi everyone, with Zope 2.9 and Zope 3.2 we are switching to a time-based release cycle. Major release are supposed to appear every six months (December and June). For Zope 2.9 the schedule is as follows: - 2.9 beta 1 on 2005-11-07 - 2.9 beta 2 aka RC1 on 2005-11-20 - 2.9 final on 2005-12-01 The 2.9 SVN branch will be created for the 2.9 beta 1 release. After creation the 2.9 branch will be feature-frozen and open only for bug-fixes. The trunk is then open again for new features (Zope 2.10). We are planning a bug day for Zope 2.9 and Zope 3.2 for this Friday, November 4th (somewhere on irc.freenode.net, channel to be announced). Cheers, Andreas

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 29 Oct '05

29 Oct '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by '<unknown>': <no reason specified> Build Source Stamp: None Blamelist: BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Mountpoints
by Jim Fulton 29 Oct '05

29 Oct '05

I was just reminded (by a zope3-dev question) of mount points. Zope2 has a mount-point capability that requires baboon patching of ZODB. The ZODB that will be used for Zope 2.9 has a multi-database feature that would allow a much simpler Zope 2 mount implementation that would not require even monkey patching of ZODB. It also, I think, would provide much more robust mounting behavior. It would be great if someone would update mounting for Zoep 2.9 to use multi-databases. I'd be happy to provide advice for such an effort. Of course, this would need to be completed before the November 1 feature freeze. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

5 39

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev October 2005