- Zope-Dev - Zope lists

Zope tests: 8 OK
by Zope tests summarizer 02 Dec '05

02 Dec '05

Summary of messages to the zope-tests list. Period Thu Dec 1 12:01:02 2005 UTC to Fri Dec 2 12:01:02 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:15:43 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003690.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:17:13 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003691.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:18:44 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003692.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:20:14 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003693.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:21:44 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003694.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:23:14 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003695.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:24:44 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003696.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:26:14 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003697.html

1 0

Short tutorial on I18n with Five
by Philipp von Weitershausen 01 Dec '05

01 Dec '05

I'm happy to announce that I've finally managed to document the internationalization (i18n) features that Five has brought to the Zope 2 world since version 1.1: http://worldcookery.com/files/fivei18n This short tutorial compares current Zope-2-based solutions to the i18n problem with the Zope 3 i18n framework. It also gives a few pointers on how to use the latter in Zope 2 applications through the means of Five. It is not a full-blown tutorial and it expects the reader to be quite familiar with i18n-aware software development in Zope already. Target audience is mostly people switching over their Zope 2 products to Zope 3 technology which i18n is a part of. The tutorial also serves as a documentation of a new Zope 2 core feature because Five 1.3 is included in Zope 2.9 which is thus the first Zope 2 version to come with built-in i18n support!

1 0

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

Zope tests: 8 OK
by Zope tests summarizer 01 Dec '05

01 Dec '05

Summary of messages to the zope-tests list. Period Wed Nov 30 12:01:02 2005 UTC to Thu Dec 1 12:01:02 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:15:17 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003682.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:16:47 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003683.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:18:17 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003684.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:19:47 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003685.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:21:17 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003686.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:22:47 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003687.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:24:17 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003688.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Nov 30 22:25:47 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-November/003689.html

1 0

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: [CMF-checkins] SVN: CMF/trunk/ CMFSetup is dead. Long live GenericSetup!
by Chris Withers 01 Dec '05

01 Dec '05

I'm probably missing something, hence my asking. If GenericSetup is generic, why is it in the CMF repository? Sure, bundle it with CMF, like BTreeFolder2 used to be, but why not also release it seperately and have it in its own repo? cheers, Chris Yvo Schubbe wrote: > Log message for revision 40429: > CMFSetup is dead. Long live GenericSetup! > > - removed obsolete CMFSetup product > - added bbb code and __module_aliases__ to support setup tools created with CMFSetup > > Changed: > U CMF/trunk/CHANGES.txt > D CMF/trunk/CMFSetup/ > U CMF/trunk/GenericSetup/__init__.py > A CMF/trunk/GenericSetup/bbb/ > A CMF/trunk/GenericSetup/bbb/__init__.py > A CMF/trunk/GenericSetup/bbb/registry.py > A CMF/trunk/GenericSetup/bbb/tool.py > > -=- > Modified: CMF/trunk/CHANGES.txt > =================================================================== > --- CMF/trunk/CHANGES.txt 2005-11-30 12:47:07 UTC (rev 40428) > +++ CMF/trunk/CHANGES.txt 2005-11-30 22:12:58 UTC (rev 40429) > @@ -43,7 +43,7 @@ > - ActionsTool: Improved add form for 'CMF Action' objects. > Presettings can now be loaded from Action settings in setup profiles. > > - - CMFSetup and GenericSetup: Added catalog tool setup handlers. > + - CMFCore and GenericSetup: Added catalog tool setup handlers. > This includes node adapters for PluginIndexes, ZCTextIndex and ZCatalog. > Support for additional indexes can be added by providing INodeExporter > and INodeImporter adapters. All indexes are cleared by this handler, so > @@ -87,7 +87,7 @@ > > - Replaced user messages by MassageIDs to improve the i18n support. > > - - CMFDefault CMFSetup profile: Added CMF BTree Folder to the list of > + - CMFDefault GenericSetup profile: Added CMF BTree Folder to the list of > automatically instantiated types in the types tool. > (http://www.zope.org/Collectors/CMF/371) > > @@ -117,9 +117,6 @@ > > Bug Fixes > > - - CMFSetup: fixed empty attribute parsing when an encoding is > - defined. > - > - ActionProviderBase: getActionObject did stumble over newstyle Actions. > > - CMFCore.exportimport.content: Ensure that BODYFILE in our "faux" > @@ -163,6 +160,9 @@ > > Others > > + - CMFSetup and GenericSetup: Removed obsolete CMFSetup product. > + Added __module_aliases__ to support setup tools created with CMFSetup. > + > - DCWorkflow: Removed hardcoded default workflows. > > - Workflow: Removed deprecated WorkflowInformation and getActionsFor. > > Modified: CMF/trunk/GenericSetup/__init__.py > =================================================================== > --- CMF/trunk/GenericSetup/__init__.py 2005-11-30 12:47:07 UTC (rev 40428) > +++ CMF/trunk/GenericSetup/__init__.py 2005-11-30 22:12:58 UTC (rev 40429) > @@ -24,3 +24,15 @@ > interfaces=None, > icon='www/tool.png', > ) > + > +# BBB: for setup tools created with CMF 1.5 if CMFSetup isn't installed > +try: > + import Products.CMFSetup > +except ImportError: > + import bbb > + import bbb.registry > + import bbb.tool > + > + __module_aliases__ = (('Products.CMFSetup', bbb), > + ('Products.CMFSetup.registry', bbb.registry), > + ('Products.CMFSetup.tool', bbb.tool)) > > Copied: CMF/trunk/GenericSetup/bbb/__init__.py (from rev 40417, CMF/trunk/CMFSetup/__init__.py) > =================================================================== > --- CMF/trunk/CMFSetup/__init__.py 2005-11-29 20:40:33 UTC (rev 40417) > +++ CMF/trunk/GenericSetup/bbb/__init__.py 2005-11-30 22:12:58 UTC (rev 40429) > @@ -0,0 +1,16 @@ > +############################################################################## > +# > +# Copyright (c) 2004 Zope Corporation 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. > +# > +############################################################################## > +""" CMFSetup product initialization. > + > +$Id$ > +""" > > Copied: CMF/trunk/GenericSetup/bbb/registry.py (from rev 40417, CMF/trunk/CMFSetup/registry.py) > > Copied: CMF/trunk/GenericSetup/bbb/tool.py (from rev 40417, CMF/trunk/CMFSetup/tool.py) > > _______________________________________________ > CMF-checkins mailing list > CMF-checkins(a)zope.org > http://mail.zope.org/mailman/listinfo/cmf-checkins > -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

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