Zope-Dev November 2005

zope-dev@zope.dev

49 participants
81 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

Folderish or SimpleItem object types for structural content
by Martijn Jacobs 02 Dec '05

02 Dec '05

Hello guys! I have a simple question about the design of hierarchical zope product structures in Zope 2. For example, you have categories, within categories you have sub-categories, within sub-categories you have sub-sub categories, within that you have content items, within content items you have....etcetera. All those products are different 'types', with different functionality and different 'roles' as what they represent, so I write different products for every type. For every object that can contain subobjects you could derive it from 'Folder' (or Object Manager). But when you derive all these product types from 'Folder' you end up with ALOT of objects in your database. In a lot of real world cases you have categories and items, that makes things easy, but what about the structure explained above? My question for you guys is : When do you decide to make it a Folderish object which contains sub-objects, or to make it a Simple Item object with, for example, some structured XML content, or dictionary / list properties containing the 'sub-structure'? The last option is more work, because you have to write your add/edit/delete/etc code yourself, writing it with Folders makes it more easily, but then you have an explosion of objects in the ZODB. I would like to have some fresh thoughts about this, so maybe you can help. Thank you in advance, kind regards, Martijn. -- Martijn Jacobs Four Digits, internet solutions e-mail: martijn(a)fourdigits.nl | web: http://www.fourdigits.nl tel: +31 (0)26 44 22 700 | fax: +31 (0)84 22 06 117

3 6

Python2.4 Security Audit ETA???
by Alan Milligan 02 Dec '05

02 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Aeons ago someone promised that said Zope security audit of Python 2.4 was scheduled for October. I've not yet seen any happy announcements that Zope is now 2.4 compliant, and do want to highlight the importance of achieving this goal. Python2.4 has been out for almost a year now, and it's fairly ubiquitous. There've been many statements made on this list about people quite happily running their Zope's - contrary to white hat advice. With the major distro's, Python is entrenched in their installer and gui processes and *all* packaging is focused around a single python (2.4 for everyone excepting our BastionLinux). In reality it is infeasible to support a second version of Python for Z2. Many modules have SWIG bindings (while core Z2 doesn't require much of this, a number of products do), requiring multiple package versions - build systems cannot cope with this scenario without massive spec customisations (which is all pointless given the window of this requirement - and of course that we've all actually learnt something for python2.5, python2.6 ....) We are getting an increasing number of people attempting to load incompatible packages. It is not possible to downgrade python. Most of userland is not competent to get a secondary python2.3 installation running - especially when packages such as python-ldap are simply not available for their old python and new ldap etc etc which all requires custom package builds. We are also stuck in a time-warp actually having to back-port a large proportion of recent linux packages because we'd like to make new features available, increasing costs and testing requirements. It is also no longer possible for customers to subscribe to just a single channel because our core is substantially different to their chosen vendor's installation, and packages will be installed into meaningless python paths etc. Can someone please give me an ETA on this, so I can decide if and how to support zope in light of other pressing linux requirements for our distro. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDi/JXCfroLk4EZpkRAlGgAKC1ZjYut1GG55TlxUyVxtD1y+YLKgCg1IV6 vsT9SOOBMUxBP4i1qo7+7q0= =MuMS -----END PGP SIGNATURE-----

7 9

zope.conf extensibility
by Sidnei da Silva 01 Dec '05

01 Dec '05

This might be the third time I hit this issue, and I've always given up before. I hope this is the last time. I have some product that would greatly benefit from being able to be configured from within zope.conf. I don't want a separate configuration file. Period. Why? Apache doesn't have separate configuration files for mod_cache or mod_anything. Chris McDonough has used the %import feature on ClockServer product, but that just works because zopeschema.xml has a <multisection> definition for ZServer.server type. I think it would be very useful for zopeschema.xml to have a <multisection> for some abstract type to allow third-party product to define their own section type extending this abstract type and thus have their configuration kept inside zope.conf Consider this a proposal *wink*. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com

3 6

Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
by Stephan Richter 01 Dec '05

01 Dec '05

On Wednesday 23 November 2005 10:16, Philipp von Weitershausen wrote: > Sounds crazy, I know. But I'm serious. Looking for your comments at: > http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository I am -1. If I could I would veto this proposal. Here is why: To be totally honest, I really, really don't care about Zope 2! I am a Zope 3 developer. If Zope 2 code is in the Zope 3 code base, I have to relearn it again and additionally learn Five. Why? Just so I can keep developing Zope 3. This may raise the contribution bar too high for me and I would consider stopping to contribute. If the bar is too high for me, what do you expect from other people? Next, there are several third party applications that do not care about Zope 2 either, but that use the trunk to do their development with. One example is SchoolTool. Having to checkout both, Zope 3 and 2 would just be ridiculous, to say the least! (Note that several contributions of mine during the last weeks were due to my work on SchoolTool using a writeable Zope 3 trunk checkout.) The proposal only benefits Zope 2 people, really. Sure, some of the stuff in Zope 2 that should be forward-ported, but that's minimal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

10 18

DateTime iso8601 bad handling of dates
by Evan Simpson 01 Dec '05

01 Dec '05

This has been brought up and (rather cavalierly) dismissed before. I challenge anyone to justify the following DateTime behavior: >>> DateTime('2005-01-01').strftime('%Y-%m-%d') '2004-12-31' DateTimes are actually timestamps, and the current implementation assumes that a date in ISO8601 format without a timezone specifier is UTC rather than local. It was asserted, last time this came up, that this is compliant with the ISO8601 spec, but my own research shows this to be false. If someone can point me to a truly authoritative source that supports the current behavior, I would appreciate it, but that would not change the fact that the manifested behavior is *broken*. This is a simple two-line fix, folks. I've already done it on my production systems. Cheers, Evan @ 4-am

2 1

Re: DateTime mess
by Tres Seaver 01 Dec '05

01 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Andrew Milton wrote: >>-1 for any scheme that involves diddling the ZODB to 'fix' pickles, because >> you just know you're going to corrupt someone's ZODB, and that's just >> noone's idea of fun. > > There are sensible ways of upgrading the ZODB. Zope 3 has had it since > 3.0 (called generations) and they've been working reasonably well for > these things. They aren't well-enough "battle tested" to make Andrew's point invalid, I think (there *are* no "large" ZODB-based Zope3 sites which have undergone generational upgrades). Frankly, anything which attempts to "fix pickles" in-place smells bad to me. "Dump and reload" is how the RDBMS world handles this kind of problem, and it isn't because they don't have smart folks working on them. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDiwO++gerLs4ltQ4RAtYdAJ9Y+UDQMou8K7fn/abJiLNkxs7TUwCfauQv woKSNYi9MFGsJKGh+FZGr7c= =929F -----END PGP SIGNATURE-----

6 10

Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
by Jim Fulton 30 Nov '05

30 Nov '05

Philipp von Weitershausen wrote: > Sounds crazy, I know. But I'm serious. Looking for your comments at: > http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository I love this idea! But I think it's still a bit too early to pursue it. In the next release cycle, I want to, finally, revisit what Zope 3 itself should be, especially the idea of "core". A couple of years ago, in the Zope 3 community, we debated what should be in "the core" of Zope 3. At the time. I fealt that that such a debate would be too much of a distraction. Now (well, after the December release :), I think it's time to revisit what the core of Zope 3 is and how we manage the repository. There has been a trend to manage important components separately and link them in. I see this trend continuing. The advent of eggs and continuing maturation of zpkg and testing technology will accelerate this trend, IMO. I think that in the future, there may be a much smaller core Zope 3 project that represents the "object filing system" (zope.ofs? :). This core project may be a client of a collection of much smaller projects, such as zope.interface, zope.component. etc.. If that vision comes to pass, Zope 2 will no longer contain the Zope 3 core, but they will both share a large number of components which neither of them "contain". Obviously, this would radically change the nature of this debate. On the topic of leveraging Zope 2 developers for Zope 3, I'd first like to leverage more Zope 2 developers for Zope 2. :) I'd like to see people focussing more effort on the Zope 3 in Zope 2 work and narrow the gap between Zope 2 and Zope 3. I'm thrilled with the effort you and others have put in and am very hopeful that the Goldegg initiative will focus more effort here, as it already has. Some projects that I'd really like to see worked on soon: - Use a common publisher framework - Use a common security framework - Share common ZPT implementations I'd love to participate in some sprints on these. After these things are done, and after we've had a chance to revisit the Zope 3 software organization, would be a good time to revisit how the Zope application server efforts should be managed. I really want to reunite the Zope 2 and Zope 3 comunities. I'd be happy if, by the end of 2006 we could retire the Zope 3 lists and merge the discussions back into the main zope lists. Jim P.S. Wow, what a huge number of messages in a day. :) -- 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

7 8

RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
by Roger Ineichen 30 Nov '05

30 Nov '05

Hi Philipp [...] > Sounds crazy, I know. But I'm serious. Looking for your comments at: > http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeR > epository Yes, you are right this sounds crazy. Reading the response to this mail, I guess developer working on existing Zope2 projects agree on this proposal. And developer where build projects only based on Zope3 will not. As somebody how don't know Zope2 I'm -1 on this. Regards Roger Ineichen > Philipp > > _______________________________________________ > Zope3-dev mailing list > Zope3-dev(a)zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > >

7 15

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

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 November 2005