[Zope-dev] Re: names starting with '@' are not reserved
Hi Philipp! Philipp von Weitershausen wrote: Dieter Maurer wrote: Chris McDonough wrote at 2006-3-13 10:21 -0500: ... silly id restrictions ... Here's my current monkeypatch to Zope to unrestrict a good number of characters: def patch_objectmanager_badid(): Causes Zope to be less restrictive in the set of characters it accepts as valid within object identifiers. Added as acceptable: []*'!:@#=+$ import re acceptable = r'[^a-zA-Z0-9-_~,.$\(\)\[\]\*\'\!\:[EMAIL PROTECTED]\#\=\+\$ ]' bad_id = re.compile(acceptable).search import OFS.ObjectManager OFS.ObjectManager.bad_id = bad_id The projects that use this patch have been in use for several years; they predate Five. I of course don't mind continuing to do this, but I'd hate to have to change it temporarily (to fix this bug which actually isn't a bug for me because I don't use Five for these projects) and then change it again when we do the pluggable thing. +1 Looks as if we had very similar project requirements... Chris's and Dieter's requirements seem to even more confirm my proposal that we should propertly factor this out to a name chooser adapter that everyone can configure for themselves. Then this discussion what ObjectManager should do or not do will become irrelevant because it won't do anything anymore :). This is actually how Zope 3 containers work. They perform no name checks *at all*. It's the application (in particular, the adding view) that does it. Zope 2's ObjectManager class is not as abstract as Zope 3 containers are. It provides a lot of folder specific behavior. I guess it would be better to subclass ObjectManager from a generic container class than trying to move all non-generic code in subclasses of ObjectManager. Yuppie's concern are Zope versions 2.8 and 2.9. Depends on the proposed solution for Zope 2.10. If you want to make a distinction between ObjectManager and Folder I can live with it. But Zope 2 folders should (by default) perform the same name checks as Zope 3 folders. And they don't allow names starting with '@'. I say that we'd just have to live with the fact that objects can shadow views there. Applications like the CMF can make sure that they don't on an application-level, as Chris suggests, preferrably through a name chooser adapter. I try to restate the problem: - It is quite common that normal users are allowed to add objects in Zope applications. - If views are shadowed by objects this can seriously break the app. - Good software makes sure normal users can't break the app. Zope 2's checkValidId makes sure this doesn't happen with Zope 2 folder methods, Zope 3's NameChooser makes sure this doesn't happen with Zope 3 folder views. Even the bad_id-patch described above doesn't allow to override folder methods. Making the name chooser configurable doesn't release us from the need to provide a good default name chooser. I still believe this should be fixed as I proposed, but given the resistance I give up my attempt to get this fixed. This is now http://www.zope.org/Collectors/Zope/2048 and I hope someone else will fix it. Cheers, Yuppie ___ 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: characters allowed in object IDs
Dieter Maurer wrote: yuppie wrote at 2006-3-10 20:20 +0100: ... To support WebDAV as widely as possible, I would prefer to get rid of all id restrictions. I do not like to see new restrictions emerging... You just don't like it or do you know a better alternative? We need a way to make sure that object IDs can't mask browser views and resources. The current solution in Zope 3 is to reserve names starting with '+' and '@' for resources and views. _ is already disallowed at the beginning of an id. Could you use it to mark views/ressources? It's more easy to customize that stuff in Zope 3 than in Zope 2, but I doubt the default names used in Zope 3 will be changed. And I don't think it would be a good idea to introduce different naming conventions in Zope 2. Compared to Zope 2.8.1 and earlier this is no new restriction. In order to support WebDAV as widely as possible, I have removed almost all id restrictions quite some time ago. I hope that this will happen in the official Zope as well. The current state of affairs is not really justified. To reach that goal more fundamental changes are necessary. While the subject of this thread is more general, I just want to fix a bug. And I doubt the fix I proposed will make the WebDAV support much worse. Cheers, Yuppie ___ 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: names starting with '@' are not reserved
Philipp von Weitershausen wrote: yuppie wrote: In Zope 3 the NameChooser makes sure you can't use content IDs starting with '+' or '@'. Zope 2 doesn't allow '+' in content IDs (actually the error message says the ID contains characters illegal in URLs), but you can use content IDs like '@@edit.html'. If the lookup order is changed as proposed (http://codespeak.net/pipermail/z3-five/2006q1/001186.html) this allows to override views with content objects. I guess this is a bug I wouldn't say that. It's just that something Five added (Zope 3 view lookup) doesn't work in all cases of legal Zope 2 object names. That's Five's problem, not Zope 2's (strictly speaking). I don't understand that differentiation. Five is part of Zope 2, so each Five issue is also a Zope 2 issue. and should be fixed in Zope 2.8, 2.9 and trunk. We'd be changing Zope 2's behaviour (not fixing a Five bug), I would therefore vote for making this change on the Zope 2 trunk only. Fixing a bug sometimes requires to change the behavior. Cheers, Yuppie ___ 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: names starting with '@' are not reserved
Hi! Philipp von Weitershausen wrote: Chris McDonough wrote: and should be fixed in Zope 2.8, 2.9 and trunk. We'd be changing Zope 2's behaviour (not fixing a Five bug), I would therefore vote for making this change on the Zope 2 trunk only. I'd be apt to not further restrict the set of identifiers an OFS content object can begin with as long as we can get away with it. If a user happens to enter one that starts with a view character, I suspect a developer could just choose to not allow this in at the application level if he cared (e.g. if he were using Five). It might be reasonable to add this to CMF instead of Zope, but IMO, it's a bad idea to put theis particular restriction in either place, as it will almost certainly break somebody. Yup. That's why we should do this change on the trunk IF at all. I doubt this will break a significant amount of code. The restriction was removed 5 months ago and AFAICS it was removed to allow email addresses as IDs. That use case will not be broken if we disallow again IDs starting with '@'. Note that even in Zope 3 the suggested behaviour is only the default and can be changed. Custom name chooser adapters may decide whether names are good or not based on whatever rule. Therefore, if we introduce this restriction, it should be pluggable like in Zope 3. If we ignore for a moment the fact that for the last 5 months the hole was open reserving '@' for views doesn't introduce any new restriction in Zope 2. '@' was always disallowed. Removing that restriction for the first character was a mistake. I just want to revert that part of the change until we have a pluggable solution. Here's what we could do: We factor the name validation part in ObjectManager (which is _checkId) out to a namechooser adapter. Five already has one in Five.browser.adding. This is obviously the Right Thing to do in the long term. But doesn't help us resolving the bug in Zope 2.8 and 2.9. Then, we can also provide an optional namechooser adapter that enforces the additional restrictions. People could decide to use this for their folder implementation, e.g. the CMF might want to do it for their folders. We already have @@manage_interfaces and Zope 2 containers will have more Zope 3 style views in the future. So I think the default in OFS should be the same as the default in Zope 3. Cheers, Yuppie ___ 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: names starting with '@' are not reserved
Hi Chris! Chris McDonough wrote: I doubt this will break a significant amount of code. The restriction was removed 5 months ago and AFAICS it was removed to allow email addresses as IDs. That use case will not be broken if we disallow again IDs starting with '@'. It seems that you can reasonably easily apply the @ restriction in your own app code under 2.8 and 2.9 until we get around to doing the right thing by making this pluggable via the namechooser thingy, no? I dunno. The current set of restrictions is too restrictive for real world use when you use Zope heavily as a fileserver, say via DAV. I wouldn't treat the existing or older restrictions as gospel as a result. I had actually been meaning to get around to unrestricting the set of identifiers in the trunk. I'd like to see this improved. But I think we need a solution that works by default with Zope 3 style views. Here's my current monkeypatch to Zope to unrestrict a good number of characters: [..] The projects that use this patch have been in use for several years; they predate Five. I of course don't mind continuing to do this, but I'd hate to have to change it temporarily (to fix this bug which actually isn't a bug for me because I don't use Five for these projects) and then change it again when we do the pluggable thing. I suppose I wouldn't care if the change was isolated to the bad_id regex, given that I replace it anyway. I'm not concerned about my own app code. I know the problem and how to fix it. And I'm not concerned about people like you who monkeypatch that code. You know that monkeypatching is always on your own risk and you know how to modify your monkey patch even if more code is changed than 'bad_id'. I'm concerned about the people we encourage to use Five technology. Views are a major feature of Five. Should we warn people not to use views? Or instruct them how to patch Zope 2 to protect views against being masked by content IDs? Cheers, Yuppie ___ 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: names starting with '@' are not reserved
Hi Paul! Paul Winkler wrote: On Mon, Mar 13, 2006 at 07:06:28PM +0100, yuppie wrote: I'm concerned about the people we encourage to use Five technology. Views are a major feature of Five. Should we warn people not to use views? Or instruct them how to patch Zope 2 to protect views against being masked by content IDs? Or just document a warning that content whose ids begin with @@ can mask views? I'm wondering if this is a case of Doctor, it hurts when I do this... It's quit common that normal users of Zope applications are allowed to add content. You can educate programmers, but you can't solve a problem like this by educating (sometimes untrusted) users. They can easily screw up a Zope app by overriding important views. And if they can do it some (untrusted) users will do it. Cheers, Yuppie ___ 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] characters allowed in object IDs
Hi! As of Zope 2.8.2 (http://svn.zope.org/?rev=38738view=rev) the '@' character is allowed in object IDs. Zope 3 does not allow object IDs starting with '@' because those names are reserved for views. Five makes Zope 3 style views available in Zope 2, so IDs starting with '@' should be disallowed in Zope 2 as well. If there are no objections I'll fix that in Zope 2.8, 2.9 and trunk. Cheers, Yuppie ___ 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: characters allowed in object IDs
Max M wrote:
yuppie wrote:
As of Zope 2.8.2 (http://svn.zope.org/?rev=38738view=rev) the '@'
character is allowed in object IDs.
Zope 3 does not allow object IDs starting with '@' because those names
are reserved for views.
Five makes Zope 3 style views available in Zope 2, so IDs starting
with '@' should be disallowed in Zope 2 as well.
If there are no objections I'll fix that in Zope 2.8, 2.9 and trunk.
[...]
If you just want to prohibit id.startswith('@') it is fine by me.
I didn't propose to revert revision 38738, just want to fix it by adding
if id[:1] == '@':
raise BadRequest('The id %s is invalid because it begins '
'with @.' % id)
So I count your reply as a +1.
Cheers, Yuppie
___
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: characters allowed in object IDs
Dieter Maurer wrote: yuppie wrote at 2006-3-10 12:14 +0100: As of Zope 2.8.2 (http://svn.zope.org/?rev=38738view=rev) the '@' character is allowed in object IDs. Zope 3 does not allow object IDs starting with '@' because those names are reserved for views. Five makes Zope 3 style views available in Zope 2, so IDs starting with '@' should be disallowed in Zope 2 as well. If there are no objections I'll fix that in Zope 2.8, 2.9 and trunk. To support WebDAV as widely as possible, I would prefer to get rid of all id restrictions. I do not like to see new restrictions emerging... You just don't like it or do you know a better alternative? We need a way to make sure that object IDs can't mask browser views and resources. The current solution in Zope 3 is to reserve names starting with '+' and '@' for resources and views. Compared to Zope 2.8.1 and earlier this is no new restriction. Cheers, Yuppie ___ 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: Deprecating Zope 2 interfaces?
Chris Withers wrote: Philipp von Weitershausen wrote: That's a bold assumption. It's a bold assumption based on the fact that I'm pretty sure there's about 1 person on the planet who's ever used that code. I believe his name's Andreas. I might be wrong of course, but I don't think it's much more than that... I guess you are just talking about IFAwareObjectManager, not about WriteLockInterface and PluggableIndexInterface. You might want to grep through CMF 1.6 or CMF 2.0 to adjust your assumptions. IFAwareObjectManager is used in several places. Cheers, Yuppie ___ 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: Deprecating Zope 2 interfaces?
Hi Philipp! Philipp von Weitershausen wrote: I don't think it will make much sense to keep Zope 2 interfaces around for more than one year from now. In other words, I'm suggesting to deprecate them for Zope 2.10. +10 But we can't deprecate z2 interfaces as long as Zope 2 itself uses them for other tasks than providing backwards compatibility. There are still some unconverted z2 interfaces in Zope 2. There are a few places in Zope 2 where they are still used for checks (mostly webdav, OFS, ZCTextIndex). In detail these are: 1.) WriteLock: Objects are only lockable if their class has WriteLockInterface in its __implements__ list. 2.) PluggableIndex: Indexes for ZCatalog have to be registered in Products.meta_types with PluggableIndexInterface. 3.) IFAwareObjectManager and the 'interfaces' argument of ObjectManager.all_meta_types: The mechanism used for pluggable indexes has a generic implementation in ObjectManager and can be used by any subclass of IFAwareObjectManager. For the deprecation period, these checks will have to be done against both the Zope 2 and the Zope 3 interface. In Zope 2.9 these mechanisms already work alternatively with z3 interfaces. There should be no need to use z2 interfaces in products written for Zope 2.9. I think this is as hard as it gets for the switch-over to Zope 3 interfaces, but perhaps I'm missing something. Don't think so. But there might be other z2 interfaces in use. Cheers, Yuppie ___ 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: Deprecating Zope 2 interfaces?
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: There are a few places in Zope 2 where they are still used for checks (mostly webdav, OFS, ZCTextIndex). In detail these are: 1.) WriteLock: Objects are only lockable if their class has WriteLockInterface in its __implements__ list. OFS.PropertySheets also does this. 2.) PluggableIndex: Indexes for ZCatalog have to be registered in Products.meta_types with PluggableIndexInterface. 3.) IFAwareObjectManager and the 'interfaces' argument of ObjectManager.all_meta_types: The mechanism used for pluggable indexes has a generic implementation in ObjectManager and can be used by any subclass of IFAwareObjectManager. Thanks for tracking those down. According to a search for 'isImplementedBy' (the old interface API method), there's also: 4) OFS.DTMLMethod and ZPublisher.HTTPResponse check for IStreamIterator 5) Products.Trancience checks for TransientItemContainer (no leading I) We should put #BBB comments to all of those locations so we won't forget. Well. All those locations import z2 interfaces so it should be quite easy to find them as soon as the z2 interfaces are removed. For the deprecation period, these checks will have to be done against both the Zope 2 and the Zope 3 interface. In Zope 2.9 these mechanisms already work alternatively with z3 interfaces. Not all of them but most of them. I just meant those 3 mechanisms on my list. 4) and 5) are not migrated, but there should not be many third party products that depend on them. I think this is as hard as it gets for the switch-over to Zope 3 interfaces, but perhaps I'm missing something. Don't think so. But there might be other z2 interfaces in use. Sure, which is why we have the deprecation period for 12 months after the Zope 2.10 release so that 3rd party software has time to switch. Sure. I meant in use in Zope 2 itself. But your search for 'isImplementedBy' should have revealed most of them. Though I believe that most of the big projects have already switched their interfaces to Zope 3 ones, only keeping the old ones for backward-compat. Zope 2.8 compatible products still have to use WriteLockInterface and z2 interfaces for IFAwareObjectManager. Cheers, Yuppie ___ 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: RFC: _verifyObjectPaste cleanup
Hi Dieter! Dieter Maurer wrote: yuppie wrote at 2005-12-2 16:50 +0100: ... checkPermission now respects proxy roles, so this workaround is no longer needed. But we should also have some way to check permissions without proxy roles: It sometimes is useful for something with a proxy role to check whether the user (without a proxy) could perform the operation as well. Thus, if checkPermission changed its behaviour, it probably should get an optional parameter to get the old behaviour back. Sounds reasonable, but I didn't fix checkPermission and I don't feel responsible for adding a parameter like that. Maybe this is something for the collector... Otherwise, I am happy with your cleanup. Fine. Cheers, Yuppie ___ 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] RFC: _verifyObjectPaste cleanup
Hi! Basically I'd like to remove the workaround introduced to fix http://www.zope.org/Collectors/Zope/78 : http://svn.zope.org/Zope/trunk/lib/python/OFS/CopySupport.py?view=diffr1=24022r2=24021 checkPermission now respects proxy roles, so this workaround is no longer needed. Replacing the workaround by a checkPermission call will make the 'permission' key in all_meta_types required, the 'action' key becomes optional. The old code did have a fallback for meta_types without 'permission' key. This is the comment for the fallback: # XXX: Ancient cruft, left here in true co-dependent fashion #to keep from breaking old products which don't put #permissions on their metadata registry entries. Is it save to make the 'permission' key required? Or do we need the fallback for 'ancient cruft'? There might be new products that don't set the 'permission' key because it wasn't enforced until now. I propose to - leave Zope 2.7 untouched - use checkPermission in Zope 2.8 and add the fallback with deprecation warning - make the 'permission' key required in Zope 2.9 and later Any comments? Cheers, Yuppie ___ 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 2 license
Andreas Jung wrote: --On 18. November 2005 21:16:11 +0800 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Zope/doc/LICENSE.txt still is ZPL 2.0 and so are most of the file headers in the Zope 2 source code. Newer files, especially those from Five, are ZPL 2.1, though. I think it's a good time to switch the rest of Zope 2 to ZPL 2.1. That way we only have to supply one license text. Agreed. I'll work on a script to replace the headers automatically. +1 But I'd like to propose to delete the 2.9 branch first, run the script on the trunk and recreate the 2.9 branch from the trunk. This would make the diffs much nicer when you try to compare trunk and branch. Just my 2 cents, Yuppie ___ 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: SVN: Zope/trunk/lib/python/AccessControl/ - converted interface to z3 interface.
Hi Philipp! Philipp von Weitershausen wrote: Log message for revision 39903: - converted interface to z3 interface. Changed: D Zope/trunk/lib/python/AccessControl/IUserFolder.py I think we should maybe leave the Zope 2 interfaces around for at least one release. People with custom user folder implementations might have imported this old Zope 2 interface. This change will break their products. In general I agree. But IStandardUserFolder in IUserFolder.py wasn't a Zope 2 interface. It was a quite useless base class. If any custom user folder subclasses from that class - which I don't believe - removing that base class is all that has to be done to fix that product. But if people think we should anyway give a warning first I'm fine with re-adding that file on the trunk. By the way, thanks for converting many interfaces to Zope 3 ones. For the Zope 2 ones that we're keeping around for a little while before throwing them out, have you thought about issuing deprecation warnings? zope.deprecation provides a very nice and easy to use framework for this. See zope.i18nmessageid/__init__.py for an example. Thanks for that hint. I'll follow up to this in a separate mail within the next few days. Cheers, Yuppie ___ 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: RFC: product initialization cleanup and improvements
Hi! Some things turned out a bit different than proposed, so I want to report back: 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. I wasn't able to finish this because it depends on http://www.zope.org/Collectors/Zope/1774 . See my comment in http://www.zope.org/Collectors/Zope/1885 for details. 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. Done. 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. That key is not required, but I found two places in Zope where it is used if it exists: In ProductRegistry for TTW products and in OFS.Application for refreshing products. 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. Done. Made sure ZGadflyDA and ZSQLMethods don't use the deprecated code. Given the fact that 2 Zope core products still used that code and given the feedback on this list I didn't remove the code in Zope 2.9. This should be done in Zope 2.10 instead. Cheers, Yuppie ___ 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] isDavCollection vs. isAnObjectManager
Hi! Is there any good reason why a true 'isAnObjectManager' makes an object a DAV collection? I'd like to check in this small patch on the trunk: Index: PropertySheets.py === --- PropertySheets.py (revision 39879) +++ PropertySheets.py (working copy) @@ -533,8 +533,7 @@ def dav__resourcetype(self): vself=self.v_self() -if (isDavCollection(vself) or -getattr(aq_base(vself), 'isAnObjectManager', None)): +if isDavCollection(vself): return 'n:collection/' return '' AFAICS it doesn't break anything in Zope itself and that change would allow to map folderish objects to a file instead of a directory by setting __dav_collection__ to False. Any objections? Cheers, Yuppie ___ 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: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:
Hi Philipp! Philipp von Weitershausen wrote: Log message for revision 39848: Merge philikon-zope32-integration branch. Great! This is a big step forward. * Moved to a zpkgutils-based build system, as the Zope 3.2 extension modules require to be built with it. If everything goes ahead as planned, the release tarball will also be built with zpkgutils (some work has also been done in that direction). That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox. And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up. Similar problems are reported here: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/12/compile/0 Is anybody working on resolving these issues? Cheers, Yuppie ___ 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: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:
Hi Philipp! Philipp von Weitershausen wrote: That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox. What changes are those? A fresh Zope trunk checkout works for me. Here's what I did: $ svn co svn+ssh://[EMAIL PROTECTED]/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure This fails if Python 2.4.2 is installed, but this worked: $ ./configure --with-python=/usr/bin/python2.4 [I see this is meanwhile fixed :)] $ make works and returns this message: Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory). following those instructions: $ make instance printf Zope 2.8.0-b1 \ /Zope-trunk/lib/python/version.txt /usr/bin/python2.4 /Zope-trunk/setup.py \ build_ext -i \ install --skip-build --home=/Zope-trunk running build_ext running build_headers running install running install_lib warning: install_lib: 'build/lib.linux-i686-2.4' does not exist -- no Python modules to install running install_headers [...] running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1 Same problems as reported by the buildbot. Renaming build/temp.linux-i686-2.4 to build/lib.linux-i686-2.4 and adding build/scripts-2.4 by hand made 'make instance' run. That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below). Using $ python2.4 setup.py build_ext -i 'works', but doesn't create a complete instance. Did you try to start bin/zopectl? I don't even have a bin directory. And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up. Not supported anymore is the right wording here. Basically, the configure; make; make install dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it. We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place. Thanks for clarifying. Cheers, Yuppie ___ 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] RFC: product initialization cleanup and improvements
Hi Dieter! Dieter Maurer wrote: yuppie wrote at 2005-10-27 14:45 +0200: ... 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. We already have the visibility key. Why do we need another (much obscurer) way to achieve the same thing? Because it doesn't do the same thing. 'visibility' doesn't primarily change the visibility. It controls if the meta_type is globally available (visibility='Global') or only in containers that specify one of its interfaces (visibility=None). ... 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. I hate that: While you might have the feeling that it were deprecated, 'ZSQLMethods' still use part of the old style initialization (they have an initialize but still use methods, __ac_permissions__ and __module_aliases__). Well. I think the comments in Application.install_product are very clear. 'initialize' was meant to replace the old way, not to provide a second way. I fixed ZGadflyDA and ZSQLMethods. And I occationally recommend these old style facilities. Having a warning period of 5 days (post on Oct 27; code freeze Nov 1) seems very short. What about removing the code for Zope 2.10? If the change breaks too many existing products I'm fine with leaving the code including deprecation warnings in Zope 2.9. Cheers, Yuppie ___ 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] RFC: product initialization cleanup and improvements
Dieter Maurer wrote: yuppie wrote at 2005-10-27 14:45 +0200: 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. I hate that: While you might have the feeling that it were deprecated, 'ZSQLMethods' still use part of the old style initialization (they have an initialize but still use methods, __ac_permissions__ and __module_aliases__). __module_aliases__ are not affected by that change. They are not initialized by Application.install_product. Cheers, Yuppie ___ 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] RFC: product initialization cleanup and improvements
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 ___ 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: RFC: product initialization cleanup and improvements
Hi Tres! Tres Seaver wrote: yuppie wrote: 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. +1. Ouch! I thought everything is in place for that feature, but an important piece of the puzzle is missing: The fix for checkPermission. http://www.zope.org/Collectors/Zope/1774 _verifyObjectPaste uses a hack to work around that checkPermission issue, making 'action' required. Tres: You did have a look at issue #1774 a while ago. What do you think: How much work would it be to resolve this issue? I'm not a C programmer so I can't do it myself... 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. I'd just as soon rip old-style interfaces out by the roots. +1 for allowing new-style ones in 2.8.x; -1 for continuing to support old-style ones on the trunk (anybody clever enough to use the old ones back in the day is clever enough, and should be motivated enough, to convert). My goal is to make it possible to run products on Zope 2.9 without implementing any old-style interfaces. I think that's doable. But I can't see a need to break all products that use old-style interfaces. Cheers, Yuppie ___ 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] last minute Zope 2.8.1 changes
Hi! If there are no objections, I'd like to merge two changes into the Zope-2_8-branch before 2.8.1 is released: 1.) Backports from zope.tal to TAL and a small modification of ustr: http://svn.zope.org/?rev=37613view=rev http://svn.zope.org/?rev=37614view=rev This is a fix needed by Five to handle massageIDs correctly. I don't expect any backwards compatibility issues. 2.) Backport of Interfaces.bridge from the Zope trunk: http://svn.zope.org/?rev=33270view=rev This is a new utility function for z2 - z3 interface migration. It doesn't change any existing code, so there should be no risk. I guess it would be useful for many products, at least CMF trunk could benefit from that bridging code. Any comments? Cheers, Yuppie ___ 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: bridging Zope core interfaces - a small proposal
yuppie wrote: I propose to move the Five bridging code (bridge.py, fiveconfigure.createZope2Bridge and related tests) to the Interface package of Zope 2. Five would still ship with a copy of that code for Zope 2.7 backwards compatibility. Based on a suggestion from philiKON and some discussion on IRC I modify my proposal: The bridging code added to Interface should work the other way round, bridging newstyle interfaces to oldstyle interfaces. Existing Zope 2 interfaces should be converted to Zope 3 interfaces and bridged back to Zope 2 interfaces for backwards compatibility. Cheers, Yuppie ___ 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] bridging Zope core interfaces - a small proposal
Hi! Five comes with some code that bridges Zope 2 interfaces to Zope 3 interfaces. This way Zope 2 interface definitions can be reused without adding redundant code. This is quite useful, but doesn't work for Zope core interfaces: Five depends one many Zope core packages and using Five code in these packages creates circular imports. I propose to move the Five bridging code (bridge.py, fiveconfigure.createZope2Bridge and related tests) to the Interface package of Zope 2. Five would still ship with a copy of that code for Zope 2.7 backwards compatibility. Any comments? If there are no objections, I'll check in these changes. Cheers, Yuppie ___ 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: bridging Zope core interfaces - a small proposal
Lennart Regebro wrote: On 7/6/05, yuppie [EMAIL PROTECTED] wrote: Five comes with some code that bridges Zope 2 interfaces to Zope 3 interfaces. This way Zope 2 interface definitions can be reused without adding redundant code. This is quite useful, but doesn't work for Zope core interfaces: Five depends one many Zope core packages and using Five code in these packages creates circular imports. Did I understand that correctly, it is a problem if you want to use Five *from* zope core code? Correct. It's not always a problem, but the bridging code doesn't depend on anything else in Five, so I guess moving that code into the core would be a clean solution. Cheers, Yuppie ___ 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] Zope 2.8: ZODB fix breaks undoable_transactions
Hi! http://svn.zope.org/?view=revrev=30334 changed the behavior of undoInfo() in a way that is not backwards compatible. See http://www.zope.org/Collectors/Zope/1822 for details. I can see 3 ways to resolve this: 1.) restoring the old behavior of undoInfo() in ZODB 2.) restoring the old behavior of undoable_transactions() 3.) propagating the change to all the code that depends on undoable_transactions() I don't know all the reasons why undoInfo() was changed, so I don't know if reverting the change is an option. If 1.) is no option, I would prefer solution 2.) over 3.) Any opinions? Cheers, Yuppie ___ 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 2.8: ZODB fix breaks undoable_transactions
Hi! Tim Peters wrote: [yuppie] http://svn.zope.org/?view=revrev=30334 changed the behavior of undoInfo() in a way that is not backwards compatible. That's true, or at least off-by-one different than recent ZODB 3.2s. Rev 30334 fixed two bugs in the implementation, so that the behavior matched what the documentation has always said undoInfo() did. I don't know when the implementation got out of synch with the docs, AFAICS there were no related changes in App.Undo.UndoSupport or undo.dtml within the last 5 years, so I guess the 'broken' behavior existed for quite a while and all existing code that uses undoInfo() or undoable_transactions() depends on the old behavior. but however people want to resolve this I will not leave the implementation disagreeing with the docs. Don't know what other people think. I believe restoring the old undoInfo behavior and adjusting the documentation would be the best solution. Fixing this in undoable_transactions would fork the behavior of both methods and fixing all products that depend on the old behavior would cause unnecessary trouble. Cheers, Yuppie ___ 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 2.8: ZODB fix breaks undoable_transactions
Tim Peters wrote:
[yuppie]
...
Don't know what other people think. I believe restoring the old undoInfo
behavior and adjusting the documentation would be the best solution.
Fixing this in undoable_transactions would fork the behavior of both
methods and fixing all products that depend on the old behavior would
cause unnecessary trouble.
Can you document the behavior you want? Because there were multiple
bugs in the implementation before, I'm not exactly sure what old
behavior was in all cases; I'm certain that _some_ of it was purely
accidental, never intended, and utterly surprising (when last 0).
ZODB/interfaces.py's IStorageUndoable.undoLog documents the current
behavior, which matches what ZODB's UML docs have always claimed
behavior should be. This behavior is tested in ZODB too now, so any
change here requires fiddling code, docs and tests. If Zope requires
particular behaviors, it should grow tests for those too.
I'd be happy enough changing `first` and `last` to act like Python
slice indices instead, with the caveat that because there's other
weird non-Python behavior mandated when last 0 (then undo{Log,Info}
are documented as taking the absolute value of `last` as being an
upper bound on the # of results to return -- and old behavior was
related to that, albeit with bugs of its own), they cannot act like
Python slice indices unless `first` and `last` are both non-negative.
Zope 2 uses 'undoInfo' only in one place: 'undoable_transactions'. And
'undoable_transactions' is only used for the undo tab.
CMF uses 'undoable_transactions' in a similar way than Zope 2. The
problem with the CMF code is that it should work in a consistent way
with Zope 2.7 and 2.8.
These are the two use cases I'm aware of. Both only use last 0 and
both expect slicing behavior for positive values, e.g. these conditions
should be True if we don't change undoable_transactions::
db.undoInfo(0, 20) == db.undoInfo(0, 99)[0:20]
db.undoInfo(20, 40) == db.undoInfo(0, 99)[20:40]
I don't care very much *how* this is resolved. All I want is to get the
regressions in Zope 2 and CMF fixed.
Cheers, Yuppie
___
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: WinBuilders for Zope 2.8
Hi Mark! Mark Hammond wrote: I think we have 2 issues here: * There is a bug in ZConfig such that if a default is provided for *both* hostname and IP, things don't behave as expected. This bug probably exists on all platforms, but is only seen on Windows since it provides defaults for the 2 values. Can't follow you. Please have a look at my summary in Entry #22 of http://www.zope.org/Collectors/Zope/1507 * It is still unclear why Windows has a different default in the first place. Tim explained that in Entry #5 of http://www.zope.org/Collectors/Zope/1728 Thus there seem to be 2 ways to move forward: 1) Remove the different behaviour for Windows. This is already done (in Zope, not in ZConfig). See http://svn.zope.org/?view=revrev=30303 2) Fix the underlying ZConfig error, and document somewhere the reasons for the change. Fred volunteered to resolve the ZConfig issue, see Entry #23 of http://www.zope.org/Collectors/Zope/1507 Cheers, Yuppie ___ 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: ZConfig change breaks Zope 2 and Zope 3
Derrick Hudson wrote: On Sun, May 08, 2005 at 02:28:55PM +0200, yuppie wrote: | Hi! | | On Windows, this 15 months old change in ZConfig sets the default | hostname for inet_address to 'localhost': | | http://svn.zope.org/ZConfig/?rev=376view=rev | | I have no idea why this was changed, the checkin message is not very | helpful: fix the default hostname for address datatypes for Windows | Any comments? Search the list archives for a discussion of why that was changed. IIRC it is due to quirks in Windows' network libraries -- a test was failing because the system API to query the identity of the socket did something funny with 'localhost' vs. '127.0.0.1' and that caused the comparison in the test to fail even though there was no actual defect. OTOH, after a quick look at the referenced defects and archived emails I may be remembering something else. Anyways, hopefully my memory will help you. If not, well that's all I can offer. I couldn't find anything in the archives, but Tim's Entry #5 in http://www.zope.org/Collectors/Zope/1728 might explain the change in ZConfig. It seems to work around an issue with connect() on Windows. But I still believe it was wrong to change the 'inet_address' datatype in ZConfig. Cheers, Yuppie ___ 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 change breaks Zope 2 and Zope 3
Hi! On Windows, this 15 months old change in ZConfig sets the default hostname for inet_address to 'localhost': http://svn.zope.org/ZConfig/?rev=376view=rev I have no idea why this was changed, the checkin message is not very helpful: fix the default hostname for address datatypes for Windows This ZConfig change is responsible for the Zope 2.8 release blocker http://www.zope.org/Collectors/Zope/1728 (the relevant info is in http://www.zope.org/Collectors/Zope/1507) and caused similar problems with Zope 3 http://www.zope.org/Collectors/Zope3-dev/383 http://mail.zope.org/pipermail/zope3-dev/2005-March/013770.html So if nobody can tell me why ZConfig was changed, I propose to 1.) revert the change and tag a new version of ZConfig 2.) update ZEO: the ZEO tests expect the old behavior, see http://mail.zope.org/pipermail/zope3-dev/2005-March/013794.html 3.) update Zope 2 trunk and Zope 3 trunk to the new versions of ZConfig and ZEO 4.) fix http://www.zope.org/Collectors/Zope/1507 and http://www.zope.org/Collectors/Zope3-dev/383 I'd volunteer to do the necessary changes in Zope 2. Any comments? Any volunteers for the other tasks? Cheers, Yuppie BTW: Why is ZConfig not a svn:external in Zope 2 and 3? ___ 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: ZConfig change breaks Zope 2 and Zope 3
Hi Mark! Mark Hammond wrote: On Windows, this 15 months old change in ZConfig sets the default hostname for inet_address to 'localhost': ... So if nobody can tell me why ZConfig was changed, I propose to That sounds good to me, as I can't understand why Windows would be different here either. I'm sure you know Windows much better than I, so it's good to know that you don't understand that either. While looking at this, I stumbled across the following code in ZConfig/datatypes.py: ## AJ: We change 'localhost' to '' to force Medusa to use ## any network interface instead of using only 127.0.0.1. This is ## a not totally clean solution :-/ See also Collector #1507. if os.name == 'posix' and 'localhost' in hostname.lower(): hostname = '' 2 things struck me: * 'localhost' in hostname.lower() appears odd - I would expect ==. * that we probably want to do that for windows too As the comments explicitly reference 1507 and the code references 'localhost', it may be worth examining too. Well. I also stumbled over that code, but after looking at it for a while I realized get_default_host_info() is never called. So I'll remove those lines, not fix them ;) Cheers, Yuppie ___ 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 2.8 on hold
Andreas Jung wrote: in agreement with Jim Fulton and Brian Lloyd we decided to put the Zope 2.8 release on hold for now. There are several open issues related to running Zope on Windows (building, startup problems). Since we need to have a stable source code release and a stable windows release in sync, the next beta 2 will appear as soon as the major issues are fixed. This is maybe a good point for advanced Windows programmer to help out *wink* +1 Are there collector issues for the release blockers? A list of release blockers might help to find volunteers. I'd like to nominate http://www.zope.org/Collectors/Zope/1776 Cheers, Yuppie ___ 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: SVN: Zope/trunk/lib/python/Testing/ZopeTestCase/testInterfaces.py Test interfaces with verifyClass in addition to verifyObject.
Stefan H. Holek wrote: Log message for revision 30296: Test interfaces with verifyClass in addition to verifyObject. [...] +self.failUnless(verifyClass(IProfiled, Profiled)) Does failUnless make any sense here? verifyClass() is either True or raises an Exception. Cheers, Yuppie ___ 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] relocating Zope 2 core interfaces - a proposal
Hi again! As discussed two days ago, I started working on integrating Five interfaces closer into Zope 2.8. I believe I understand the problem better now and like to propose a different way to resolve it: Current State = Five (now part of Zope 2.8) ships with one big interfaces.py file that contains z3 interfaces for Zope 2 core classes. (There are also some five specific interfaces in that file, but they are not subject of this proposal.) interfaces.zcml states that Zope 2 implements these interfaces, but there are no tests to verify that and in fact many of these interfaces are broken in Five 1.0. (Yesterday I checked in some fixes to the Five trunk.) So if they are used at all in Five products, they are only used as marker interfaces, not to verify implementations. I grepped through CMFonFive, SilvaDocBook and SilvaFlexibleXML: None of them use these interfaces. Goals = Step by step, Zope 2 should move to z3 interfaces. Where z2 interfaces exist, these should be improved and bridged to z3 interfaces. Missing interfaces should be added as z3 interfaces. Instead of maintaining competing interfaces, Five should support that process. Interface locations are identifiers, so first of all I want to get these locations right before Zope 2.8 is released. Z3 interfaces should be located in an 'interfaces' module of the corresponding package. In the Five package they are unmaintainable. So e.g. instead of Products.Five.interfaces.IObjectManager Products.Five.interfaces.IWriteLock we would have OFS.interfaces.IObjectManager webdav.interfaces.IWriteLock Proposed Solution = 1.) Adding ZCML that bridges existing z2 interfaces into the 'interfaces' module of their package. [Zope 2.8.0] 2.) Copying z3 interfaces from Five.interfaces to the 'interfaces' module of the corresponding package. Marking those in Five as Zope 2.7 backwards compatibility cruft. [Zope 2.8.0] 3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+] 4.) Making interfaces.zcml point to the new locations. [Five 1.0+] 5.) Adding unit tests that verify interfaces and implementations. [Zope 2.8.0] Risks = I can't see a way to provide backwards compatibility for Products.Five.interfaces.*, but as explained above I'm hopeful this doesn't break many Five products. Any comments? Cheers, Yuppie ___ 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: relocating Zope 2 core interfaces - a proposal
Hi! Martijn Faassen wrote: Andreas Jung wrote: [snip] -1. Such changes are not much acceptable *now*. 2.b2 will be released this week and 2.8 final in about two weeks. Such changes should have been proposed during alpha phase...but I am against such change in this late release phase. For Zope 2.8 it is a low risk change and I can work on it within the next days. The problem was introduced by adding Five and the beta phase is for finding issues with new code and fixing them. That's a good point. Let's amend the plan and say we start executing this *after* Zope 2.8, possibly for Zope 2.9. I hope we can make that release cycle relatively short anyway, and driven by Five changes; this would be a good example of such. Jim may have bigger plans for deeper Zope 3 integration (such as merging the security system), but if that is going to take time then we could defer that until Zope 2.10. This way, all the work that remains for me is to merge in Five 1.0 into Zope 2.8. My point is: Doing that in a backward compatible way is impossible. So we have to do it now or never. Cheers, Yuppie ___ 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 2.8, Five and Interfaces
Philipp von Weitershausen wrote: Martijn Faassen wrote: So you would have the Zope 2.8 interfaces exist in the Five.interfaces module? Well, no. Five.interfaces would stay as it is; it seems to be pretty accurate for Zope 2.7 (especially with yuppie's fixes, which should be merged to the Five-1.0 branch, btw). Some interfaces were added to Zope 2.8 and it would make sense to manage all of them in the Zope tree for the future, not the Five tree. However, when run within Zope 2.8, we want Five.interfaces to be most accurate, so we would install bridges in Zope 2.8 that bridge the Zope 2.8 interfaces to Five.interfaces. At least that was yuppie's latest idea andI think it's elegant. Well. This was not my *latest* idea. I tried to implement it that way, but that approach has some limitations: - While we want to get rid of z2 interfaces in the long run, this requires to add z2 interfaces to Zope. - You did use schema fields for the z3 interfaces. Backporting these interfaces to z2 interfaces is a regression. - It's not as easy to import bridged interfaces as to import static interfaces. We have to make sure they are already created. Please see me new proposal, posted today. Cheers, Yuppie ___ 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: [z3-five] relocating Zope 2 core interfaces - a proposal
Hi! Martijn Faassen wrote: yuppie wrote: [snip] Current State = Five (now part of Zope 2.8) ships with one big interfaces.py file that contains z3 interfaces for Zope 2 core classes. (There are also some five specific interfaces in that file, but they are not subject of this proposal.) interfaces.zcml states that Zope 2 implements these interfaces, but there are no tests to verify that and in fact many of these interfaces are broken in Five 1.0. (Yesterday I checked in some fixes to the Five trunk.) Note that they also need to be in the 1.0 branch, if this is to be in Zope 2.8. sarcasmMaybe it's better the interfaces are broken. That makes sure people don't use them extensively and might give us a chance to relocate them at a later point./sarcasm I grepped through CMFonFive, SilvaDocBook and SilvaFlexibleXML: None of them use these interfaces. I think there's some code inside the Five tests that might use them. There's also a chance someone else is using them, but admittedly the risk of breaking something doesn't seem too big. This does deserve to be called 1.1 though if we're breaking APIs (this would then derive from the 1.0 branch, not the Five trunk). Ok. Proposed Solution = 1.) Adding ZCML that bridges existing z2 interfaces into the 'interfaces' module of their package. [Zope 2.8.0] 2.) Copying z3 interfaces from Five.interfaces to the 'interfaces' module of the corresponding package. Marking those in Five as Zope 2.7 backwards compatibility cruft. [Zope 2.8.0] 3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+] I don't understand this step; what are you proposing? It might be better to use the new locations also for Zope 2.7. But the interfaces don't exist in Zope 2.7, so we would have to inject them into Zope 2.7. 4.) Making interfaces.zcml point to the new locations. [Five 1.0+] While in Zope 2.8, we could add 'implements' in the Zope 2 code directly, we don't need to do this from ZCML anymore. As you state below, there might be issues with mixing five:implements and implements(). But if there are no issues, I agree that using implements() would be better. Another potential risk is Five doing five:implements to a class that already has a Zope 3 style 'implements()'. I don't know what happens in such a case... Cheers, Yuppie ___ 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: [z3-five] relocating Zope 2 core interfaces - a proposal
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: Seriously, you should merge your r11978 to the Five-1.0 branch.0 Martijn was faster than I thought :( I'll follow up to this in an other mail. I don't think we need to break backward compatability. We would just need to deprecate the Five.interfaces location. Basically, the goals are: * The solution needs to work with Zope 2.7 * Preferrably, the interface import spelling should be equal on both systems (which means a monkey on 2.7 is probably inevitable). * On 2.8 we want to have definitions of the z3-style interfaces in the Zope tree. * Five.interfaces and OFS.interfaces.*, etc. need to contain the exact *same* interfaces (same, not equal) on both systems at all times. That's the point I missed! So we just need code like this at the end of Five.interfaces: try: # override IObjectManager with Zope 2.8 interface from OFS.interfaces import IObjectManager except ImportError: # monkey patch Zope 2.7 OFS ... Right? * Five.interfaces should be deprecated as an import location in the long term. Fine. I no longer think we need to break backward compatibility. Cheers, Yuppie ___ 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: relocating Zope 2 core interfaces - a proposal
Philipp von Weitershausen wrote: yuppie wrote: Proposed Solution = [...] 3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+] I assume here you mean patching in OFS.interfaces, webdav.interfaces etc... Yes. 4.) Making interfaces.zcml point to the new locations. [Five 1.0+] 5.) Adding unit tests that verify interfaces and implementations. [Zope 2.8.0] IMHO that's yagni. We actually don't use interfaces that much for verifying implementations anymore. I think their most common use in Zope 3/Five is documentation, API/schema specification, and easier spelling for security declarations. ??? Who is 'we'? How do you make sure documentation and specification are in sync with the implementation? AFAICT verifyClass() is quite useful for that. Cheers, Yuppie ___ 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: relocating Zope 2 core interfaces - a proposal
Philipp von Weitershausen wrote: Martijn Faassen wrote: Yes. I still don't see where the need for incompatability is. Maybe I'm just blind. Can someone explain? I no longer see a problem. If we make sure the Five interfaces and those in the Zope tree are the same, there are no incompatibilities. By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a significant amount of work, due to all kinds of copyright headers being different). Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases are ZPL 2.1, aren't they? Are there other things you did have to change? Cool. I can imagine that it was quite dificult. By the way, I think we should have yuppie's r11978 in it (which means we need it on Five-1.0 branch and a Five 1.0.1 release, probably). Gee, I would do the merge myself my laptop wasn't broken. I'm on a Windoze machine right now on which I quickly installed Thunderbird to be at least a little communicative :). Sorry. I didn't think Martijn would merge in Five today. Please let me know if can help to put things straight. Cheers, Yuppie ___ 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: relocating Zope 2 core interfaces - a proposal
Martijn Faassen wrote: Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases are ZPL 2.1, aren't they? Are there other things you did have to change? Yes, some other things like taking out the monkey.py module, and some documentation differences. I want to get the headers in synch inside Five eventually, just didn't want to do it for Five 1.0. There is a lot of cruft in Zope 2.8. As long as the monkey patchs are disabled in Zope 2.8, I would not mind if they are shipped with 2.8. That would make it easier to update the Zope repository frequently. I'd been putting it off, and all this, especially Andreas' note, reminded me I should do it. If you can get your fixes checked into the Zope 2.8 trunk (as well as in the Five-1.0 branch) then we should be fine (assuming you can check into svn.zope.org? Otherwise just put it in the branch and I'll port it into Zope 2.8). Done. Five-1.0 and Zope trunk. Cheers, Yuppie ___ 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] Zope 2.8, Five and Interfaces
Hi! I had a closer look at Zope 2.8's Five and I'm concerned about the fact that Five ships with redundant interface definitions: - redundant code is always a problem because it's hard to keep things in sync - the fact that Five is maintained in a different repository and should work with different Zope versions makes it almost impossible to change Zope interfaces in a consistent way So my questions are: 1.) Why are interfaces that are available as Zope 2 interfaces duplicated in Five/interfaces.py instead of bridged? 2.) Could we move the interfaces that are currently not available as Zope 2 interfaces to the corresponding packages in Zope 2.8, using Five/interfaces.py just as an fallback for Zope 2.7 and old Five products? If people agree that this is problem, I'd volunteer to help resolving it. Cheers, Yuppie ___ 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 2.8, Five and Interfaces
Hi! Philipp von Weitershausen wrote: Right. Here's what we could do: 1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces I would prefer to reserve the name 'interfaces' for Zope 3 interfaces. So far ZopeTestCase is the only package in Zope 2.8 that uses 'interfaces' for Zope 2 interfaces. 2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is). 3. Add five:bridge / calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet. Would this work: Instead of modifying Five at all, could we just add zcml files to the Zope 2.8 packages with Zope 2 interfaces and override the interfaces in Five.interfaces? If you want to do this, yuppie, feel free to do it. I would even be ok for this to be done for the 1.0 branch, provided you also add it on the trunk. If I need to change something in Five: Do I need additional checkin rights on codespeak, or will my kupu login work? Cheers, Yuppie ___ 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: Windows Binaries for 2.8b1
Christian Theune wrote: Sticking to this thread ... [...] -- Ran 5634 tests in 1433.151s FAILED (failures=3, errors=2) Any comments? Still hesitating to release the binaries, but I have them around. I changed setup.py to add the files you added manually. Besides the 2 ZServer tests the same tests fail on Linux. The setup code for the Zope 3 stuff works different and I don't want to fork it. So these errors should be discussed with the Zope 3 people. I think you should release what you have now. But for the next beta these errors should be release blockers. Maybe you can run Windows tests *before* Andreas tags the next beta release? Cheers, Yuppie ___ 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: Windows Binaries for 2.8b1
Tim Peters wrote: Someone with setup.py courage needs to step up to the plate then. The Windows build process is way hard enough to follow already without adding reams of arbitrary new makefile cruft to paper over setup.py bugs. Perhaps someone on Linux could volunteer to run Zope trunk tests from the result of doing setup.py install ..., and add missing files to setup.py until that works. The WinBuilders tests can't possibly work either so long as setup.py neglects to install necessary files. Done. (besides the Zope 3 failures) I did that more than once, but why can't people clean up after themselves? AFAICS two things could help them: - giving feedback by running nightly test on a not-in-place installation - reducing the need for setup.py updates by switching to the Zope 3 setup code Just my 2 cents. Yuppie ___ 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: Windows Binaries for 2.8b1
Hi! Tim Peters wrote: [yuppie] I did that more than once, Did what more than once? Updating setup.py. (Or reminding people to do it themselves if they add new files and forget to update setup.py.) but why can't people clean up after themselves? Which people, cleaning up what? Sorry, I'm not following this. Contributers. setup.py. AFAICS two things could help them: - giving feedback by running nightly test on a not-in-place installation That would be helpful. - reducing the need for setup.py updates by switching to the Zope 3 setup code I think this gets worse with Zope3 code, and especially when mixed in with Zope2. Zope3 still uses setup.py for testing from a checkout, but uses zpkgtools for building a distribution: those two subsystems have nothing in common, and get out of synch with each other. It would be better if Z3's setup.py used zpkgtools too, but it doesn't now. In any case, nothing in Z2 (including WinBuilders) knows anything about how to live with zpkgtools now. For Zope 2.8, there may not be a realistic alternative to teaching Zope 2.8's setup.py how to install the Z3 bits in Zope 2.8. It already does this for other pieces. For example, ZODB 3.4 (which Zope 2.8 uses) inherited the same setup.py-vs-zpkgtools schizophrenia from Zope3, but Zope 2.8's setup.py learned how to install ZODB 3.4 independent of that (indeed, ZODB's own setup.py has never been part of any Zope checkout that I know of). Seems I wasn't specific enough. I just meant setup.py, not the other setup code from Zope 3. The Zope 2 code requires to specify each directory. The Zope 3 code walks through all subdirectories and searchs for files with the specified file extensions. That code is already part of the Zope 2 setup.py, but only used for the Zope 3 stuff. I didn't try it, but I guess it would not be too hard to use it for all the other packages as well. Cheers, Yuppie ___ 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: HEADS UP: QA Problems with Zope 2
Christian Theune wrote: a) I'm not able to look into the test runners (that are not broken solely on windows) nor to look into Five integration problems. I'd love if someone could a) either fix test.py or b) deprecate it and give me the hint to some other runner that works. test.py is included and should therefore work within a release or be removed. I'm not sure what is right here. I just added some missing files to setup.py. Could you please try again? There are still some broken z3 tests (setup works different for z3), but at least on linux test.py works now. Cheers, Yuppie ___ 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: HEADS UP: QA Problems with Zope 2
Tim Peters wrote: [Christian Theune] ... I have a compiled Zope 2.8a2 around here, but I'm not able to run the unit tests on it and I'm not willing to publish it therefore because I have the suspicion that this branch never has seen windows before except the one pass of unit tests before 2.8a1. FYI, I usually run the Zope trunk tests once a day, on WinXP. None of this goes thru WinBuilders, though -- this is doing test.py -vv --all from the root of a trunk checkout immediately after setup.py build_ext -i. AFAICS the problem is that *everybody* runs the tests in-place. So nobody tests if setup.py installs Zope correctly and people often forget to make sure setup.py installs newly added packages and files. Cheers, Yuppie ___ 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: [Zope2.8a2] ...to be released by tomorrow....
Tres Seaver wrote: http://cvs.zope.org/Zope/lib/python/AccessControl/Attic/ZopeGuards.py.diff?r1=1.16.2.3r2=1.16.2.4 [...] Hmm, that change hadn't landed on the gmane.org version of the checkins. I have it merged in my sandbox now, along with two apparently related changes (to the 'actual_python' and 'testZopeGuards' modules in lib/python/AccessControl/tests). That seems to be the complete change, see http://cvs.zope.org/query?branch=Zope-2_7-branchwho=evansortby=datedate=all#results Evan, do you recall whether you made related changes outside of the AccessControl package (e.g, in PythonScripts, ZPT, etc.)? HTH, Yuppie ___ 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: [Zope2.8a2] ...to be released by tomorrow....
Tres Seaver wrote: I still have a notion that some improvements made on the 2.7 branch are not merged into the SVN trunk, e.g. http://cvs.zope.org/Zope/lib/python/AccessControl/Attic/ZopeGuards.py.diff?r1=1.16.2.3r2=1.16.2.4 There is some debate here whether those changes (which Jim made only relunctantly back in January 2004) should be promulgated to 2.8. We will fold them in after the alpha, if so. The link above points to an other unmerged change. I don't understand the complete change, but at least removing Python 2.1 compatibility code should also be done on the trunk. Cheers, Yuppie ___ 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: [Zope2.8a2] ...to be released by tomorrow....
Hi Tres! Tres Seaver wrote: Please try the patch I just checked in: http://svn.zope.org/Zope/?rev=29821sortby=dateview=rev Thanks! This resolves issue #1460. Merged it into the trunk to get it into the alpha 2 release, hope that's ok. There may be additional issues (e.g., Stuart Bishop's checked __getitem__ use case), but this makes the test script and the CMF work for me. I still have a notion that some improvements made on the 2.7 branch are not merged into the SVN trunk, e.g. http://cvs.zope.org/Zope/lib/python/AccessControl/Attic/ZopeGuards.py.diff?r1=1.16.2.3r2=1.16.2.4 Cheers, Yuppie ___ 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] PageTemplate XML mode bugs
Hi! There are two annoying bugs that make the XML mode unusable for many tasks: - http://collector.zope.org/Zope/1101 (i18n namespace broken) - http://collector.zope.org/Zope/1474 (XML files opened in binary mode) I would volunteer to work on these issues, but for that it would be useful to know: 1.) Does anybody feel responsible for the TAL or PageTemplates module? 2.) What was the motivation for the original code? #1101 looks like someone just forgot to remove a debug assert in TALParser.py. The Zope3 version doesn't have that assert statement. Or was there a reason to disable i18n for XML mode? #1474 is a change backported from Zope3. It was reverted for HTML mode for apparently the same reason why the XML mode is still broken. I guess the motivation was to preserve CDATA, but I don't know that for sure. Thanks, Yuppie ___ 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] Re: PageTemplate XML mode bugs
Fred Drake wrote: On Tue, 05 Oct 2004 12:47:33 +0200, yuppie [EMAIL PROTECTED] wrote: #1101 looks like someone just forgot to remove a debug assert in TALParser.py. The Zope3 version doesn't have that assert statement. Or was there a reason to disable i18n for XML mode? That's what it looks like. The assert isn't in the Zope 3 version of the code. I suspect it can be safely removed. I've made a note of this in the tracker issue. Ok. I'll remove that line in CVS/SVN. #1474 is a change backported from Zope3. It was reverted for HTML mode for apparently the same reason why the XML mode is still broken. I guess the motivation was to preserve CDATA, but I don't know that for sure. This report isn't clear. Please update the issue and explain what the problem is; glancing at the code on the Zope 2 and Zope 3 trunks, the only thing that looks suspicious to me is that re-opening an HTML file doesn't use Python's universal newline support. HTML is always text, so should be treated that way on input. XML may contain textual content, but should always be handed to the XML parser as a raw byte stream to allow the proper decoding machinery a shot at doing the right thing. I added a new comment to the issue. Hope that makes things clearer. ( http://collector.zope.org/Zope/1474 ) Thanks, Yuppie ___ 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] Re: SVN: Zope/trunk/lib/python/Testing/ZopeTestCase/ added ZopeTestCase 0.9
Hi! Andreas Jung wrote: Log message for revision 27453: added ZopeTestCase 0.9 I didn't see any comments from the project owner. What are the plans for ZopeTestCase? Will it just be shipped with Zope or are there any plans to integrate it further with Zope? Will there be any development in the Zope repository or is the SourceForge repository still the primary location? BTW: Seems the files don't have the right mode. My Windows checkout has Unix newlines. Cheers, Yuppie ___ 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] Re: Pointless code in ZPublisher.HTTPRequest ?
Hi!
Paul Winkler wrote:
From ZPublisher.HTTPRequest.HTTPRequest.keys:
n=0
while 1:
n=n+1
key = URL%s % n
if not self.has_key(key): break
n=0
while 1:
n=n+1
key = BASE%s % n
if not self.has_key(key): break
Unless I am particularly stupid today (quite possible),
the above has no affect on the return value, and no
direct side effects.
I tried commenting it out and ran all unit tests
with no apparent difference.
While digging deeper for indirect side effects, I see that
self.has_key() calls self.__getitem__() which calls self.get().
The only side effect of self.get('URLn') that I see is that if
self.other.has_key('PUBLISHED'), the calculated URL will get
cached for the duration of the request in self.other['URLn'].
[...]
So maybe that's the sole purpose of the code in question;
some extra logging suggests that it does in fact have that effect.
But it's hard for me to be sure.
Can anyone confirm or deny?
Or is there something else that I'm missing?
In situations like that the CVS history is often quite useful:
http://cvs.zope.org/Zope/lib/python/ZPublisher/Attic/HTTPRequest.py.diff?r1=1.17r2=1.18
I'd say the sole purpose is what you describe, but the result of the
side effect is used in the next line of 'keys':
keys.update(self.other)
This small script shows that the code in 'keys' triggers the computing
of URLx and BASEx:
print context.REQUEST.other.keys()
context.REQUEST.keys()
print context.REQUEST.other.keys()
return printed
Cheers,
Yuppie
___
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] closed collector issues 1252 and 1308
Hi! Just want to let you know that I'm not happy with the way these two collector issues were resolved: http://zope.org/Collectors/Zope/1252 http://zope.org/Collectors/Zope/1308 Hope at least one of them will be re-opened. Cheers, Yuppie ___ 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] Re: Zope and zope
Jim Fulton wrote: Chris McDonough wrote: I think the breakage, although literally incalculable (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a bruce package in place that, when imported, raised a ObsoleteError with a descriptive message. But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh. Why is that a *big* problem? - It's not nice to break tests, but that doesn't necessarily mean the products are broken. - AFAICT many products need some polishing and a new release for Zope 2.8 anyway. Cheers, Yuppie ___ 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] OrderSupport: small improvement
Hi! Currently the OrderSupport API always orders sub-objects relative to the complete list of sub-objects. This causes problems if some hidden sub-objects are not shown. From an UI point of view, moving sub-objects should always be relative to the visible subset of sub-objects. I'd like to add a new optional argument to moveObjectsByDelta (and the derived methods moveObjectsUp, moveObjectsDown, moveObjectsToTop, moveObjectsToBottom): subset_ids This would be 100% backwards compatible and would allow to specify the visible subset of sub-objects. def moveObjectsByDelta(ids, delta, subset_ids=None): If subset_ids is specified, delta will be interpreted relative to that subset. If there are no objections I'll soon check in the necessary changes to Zope-2_7-branch and HEAD. Cheers, Yuppie ___ 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] setup.py and unittests
Hi! Trying to run unittests from a Zope HEAD installation, I stumbled over these setup.py issues: - the new 'transaction' package is missing - testrunner.py is installed, not test.py - some files needed to run unittests are missing - SearchIndex.UnIndex still imports BTree and IOBTree which were removed from setup.py 4 months ago Proposals: - install test.py instead of the deprecated testrunner.py - install all files needed to run the unittests - fix all test failures - would be nice if at least the nightly tests could be run from a clean new installation instead of a sandbox Cheers, Yuppie ___ 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] Re: test.py
Hi! Fred Drake wrote: On Thursday 11 March 2004 10:40 am, Tres Seaver wrote: #!/usr/bin/python2.3 distutils will munge it anyway, if it installs the scripts. That won't work for a lot of developers, I'll bet, who have python2.3 installed in /usr/local/bin. The env hack is more reasonable for developers; since distutils is going to munge the sh-bang line anyway, it's not an issue for real installations. I don't care much *how* this is resolved, but I'd like to have this consistent and up to date. If I always have to check if the python version is set correctly that line isn't helpful at all. If we can get any consensus on this question I'll volunteer to check in the changes. Cheers, Yuppie ___ 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] Re: test.py
Hi! Tres Seaver wrote: yuppie wrote: Some grep results from Zope HEAD: setup.py: #! /usr/bin/env python test.py: #! /usr/bin/env python2.2 utilities\check_catalog.py: #!/usr/bin/env python2.1 utilities\requestprofiler.py: #!/usr/bin/env python utilities\compilezpy.py: #!/usr/bin/env python utilities\zpasswd.py: #!/usr/bin/env python utilities\testrunner.py: #! /usr/bin/env python2.2 utilities\ZODBTools\space.py: #! /usr/bin/env python And many tests, some of them still with python1.5, e.g. lib\python\TAL\tests\run.py: #! /usr/bin/env python1.5 Could we have a policy for this? I guess '#! /usr/bin/env python' is easier to keep up to date ... -1. We should specify the required minimum version everywhere. I'm fine with that. The 'env' hack is evil because it pretends to be flexible, while still leaving you vulnerable to strangeness. Is there a better alternative than the 'env hack'? (I had to google to find out what you mean by 'env hack' and found http://www.faqts.com/knowledge_base/view.phtml/aid/1406, but nothing about better solutions.) BTW, the space after the '!' should go, too; it is not guaranteed to be honored by all shells. Good to know. So you propose to replace *all* the #! lines by #!/usr/bin/env python2.3 Right? Cheers, Yuppie ___ 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] Re: test.py
Hi! Jeremy Hylton wrote: test.py obsoleted testrunner.py as of Zope 2.7. test.py was being used by ZODB3 and Zope3 for a while before it was added to Zope 2.7. Why does setup.py still install testrunner.py, not test.py? And BTW: Could *all* files necessary to run tests be installed? I'm not sure which #! line you mean, but I think you're right to say it should be python 2.3. All the software on the head requires python 2.3. Some grep results from Zope HEAD: setup.py: #! /usr/bin/env python test.py: #! /usr/bin/env python2.2 utilities\check_catalog.py: #!/usr/bin/env python2.1 utilities\requestprofiler.py: #!/usr/bin/env python utilities\compilezpy.py: #!/usr/bin/env python utilities\zpasswd.py: #!/usr/bin/env python utilities\testrunner.py: #! /usr/bin/env python2.2 utilities\ZODBTools\space.py: #! /usr/bin/env python And many tests, some of them still with python1.5, e.g. lib\python\TAL\tests\run.py: #! /usr/bin/env python1.5 Could we have a policy for this? I guess '#! /usr/bin/env python' is easier to keep up to date ... Cheers, Yuppie ___ 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] Re: Call for testing (2.6.4 / 2.7.0)
Hi! Casey Duncan wrote: These tests seem pretty naive. I don't thing user objects promise to compare to one another in any way. Looks to me like the tests should be changed to something like: self.failUnless(f.getOwner() is ownership) That's not the problem. I had a closer look at this: Before the Owned API was changed getOwner() did return the wrapped user, now it returns the unwrapped user. If I replace getOwner() by the new getWrappedOwner() all tests pass. I'm not sure what this line in getOwner() means: code return aq_base(self.getWrappedOwner()) # ugh, backward compat. /code Looks like backward compatibility code that breaks backward compatibility. Cheers, Yuppie ___ 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] Re: Call for testing (2.6.4 / 2.7.0)
Hi! Brian Lloyd wrote: In the meantime, it would be helpful for anyone who runs from the 2.6 or 2.7 branches in CVS to update and let us know if you have any unresolved problems. Right now I have no time to track this down myself, but the attached CMF test failures seem to be related to the last Zope changes. Don't know if these tests need to be updated or if they reveal a bug in Zope. Cheers, Yuppie == FAIL: test_createMemberArea (Products.CMFCore.tests.test_MembershipTool.MembershipToolSecurityTests) -- Traceback (most recent call last): File /usr/local/lib/Zope-2.7/Products/CMFCore/tests/test_MembershipTool.py, line 82, in test_createMemberArea self.assertEqual( f.getOwner(), ownership ) File /usr/lib/python2.3/unittest.py, line 302, in failUnlessEqual raise self.failureException, \ AssertionError: DummyUser instance at 411215f0 != DummyUser instance at 411215f0 == FAIL: test_constructContent (Products.CMFCore.tests.test_TypesTool.TypesToolTests) -- Traceback (most recent call last): File /usr/local/lib/Zope-2.7/Products/CMFCore/tests/test_TypesTool.py, line 125, in test_constructContent self.assertEqual( f.getOwner(), acl_users.user_foo ) File /usr/lib/python2.3/unittest.py, line 302, in failUnlessEqual raise self.failureException, \ AssertionError: DummyUser instance at 41121770 != DummyUser instance at 41121770 == FAIL: test_createMemberArea (Products.CMFDefault.tests.test_MembershipTool.MembershipToolSecurityTests) -- Traceback (most recent call last): File /usr/local/lib/Zope-2.7/Products/CMFDefault/tests/test_MembershipTool.py, line 88, in test_createMemberArea self.assertEqual( f.getOwner(), ownership ) File /usr/lib/python2.3/unittest.py, line 302, in failUnlessEqual raise self.failureException, \ AssertionError: DummyUser instance at 411dd930 != DummyUser instance at 411dd930 -- Ran 366 tests in 8.800s FAILED (failures=3) ___ 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] Re: 2.7 assertion with CVS of this morning
Hi Robert!
robert wrote:
I found this,
however 'has_order_support' is not the third argument.
That is why I do not unterstand what happens.
[...]
_.hasattr(this().aq_self, 'has_order_support')
I don't know that code very well, but this is how I understand what happens:
All names in the TemplateDict are bound as methods. If you call hasattr
the TemplateDict ('self') is passed in as first argument, in our case
'has_order_support' becomes the third argument. To avoid this functions
need to be wrapped by NotBindable.
Did you see my other mail? Adding 'hasattr' (not 'guarded_hasattr') to
_NEED_WRAPPING works for me.
Cheers,
Yuppie
___
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] Re: 2.7 assertion with CVS of this morning
robert wrote: I grepped for has_order_support to find out where this happens, but did not find it. The Zope 2.7 main.dtml has this code: _.hasattr(this().aq_self, 'has_order_support') HTH, Yuppie ___ 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] Re: 2.7 assertion with CVS of this morning
Tres Seaver wrote: This is my bad, I'm pretty sure. Was this just trying to get into the ZMI, or was there another application / template which triggered the problem? At any rate, the fix is likely to be to add 'guarded_hasattr' to the list of items which should be wrapped; on the 2.7 branch, this list is at the bottom of AccessControl.Implementation. Yes. Adding 'hasattr' (the key for guarded_hasattr) to _NEED_WRAPPING seems to fix this issue. Cheers, Yuppie ___ 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] Re: On with the show....
Sidnei da Silva wrote: Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon? Maybe [EMAIL PROTECTED] is a better place for questions like that? Today Tres Seaver wrote: BTW, I plan to post a draft roadmap for CMF 1.5 soon (today, I hope), and to ask for feedback. Yuppie ___ 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] Re: api docs [Was: Re: Post-mortem ...]
Hi! Paul Winkler wrote: What would be sane in your view? Using interfaces for help, as CMF does? I was curious how CMF sets this up, and found the following in CMFCore/__init__.py: try: context.registerHelpTitle( 'CMF Core Help' ) context.registerHelp(directory='interfaces') except: # AARGH!! pass I love comments like that :-) This bare except is removed in CMF HEAD, it's not necessary for current Zope versions. http://cvs.zope.org/CMF/CMFCore/__init__.py.diff?r1=1.24r2=1.25 But there are other issues with this approach. I never got a reply to this mail: http://mail.zope.org/pipermail/zope-dev/2002-November/018103.html Maybe the Zope X3 Introspector is a sane solution? Cheers, Yuppie ___ 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] Re: Post-mortem [Was: Zope 2.7.0 b3 regressions]
Hi Evan! Evan Simpson wrote: Done and done! ??? Are you sure? Today I built Zope 2.7 from a new checkout. And all icons in the ZMI are broken :-( They have src paths starting with // I didn't have a closer look at your checkin, but I'm afraid something went wrong. Cheers, Yuppie ___ 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] api docs [Was: Re: Post-mortem ...]
Hi! Brian Lloyd wrote: Good call. I think it would be best to make sure the docstring of the new method is clear on its reason for being. I think somewhere there is an interface file that is used to generate some of the api docs - ideally that can get updated too. What is the Right Way to keep api docs in sync? Example 1: ZCatalog/IZCatalog.py seems to be more up to date, but ZCatalog/help/ZCatalog.py is used by the Zope Help System and I guess also to generate api docs. Example 2: I did add OFS/IOrderSupport.py, but how will it become part of help and api docs? Is there a better way than copying it to OFSP/help? I hate to add redundant code because - as example 1 shows - it is hard to keep the files in sync. CMF uses the interface files also as help files. As interface files become more and more common in Zope it might make sense to do the same in Zope. Cheers, Yuppie ___ 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] Re: Zope 2.7.0 b3 regressions
Hi Stefan! Stefan H. Holek wrote: absolute_url(1) was broken (by my definition of broken) basically since the introduction of VHM, which means the better part of 2 years. Naturally, there is code now that relies on this (broken) behavior. This does however not mean it should not be fixed! AFAICT 'inside-out' hosting was used long before the introduction of VHM. Using your definition of broken absolute_url(1) was broken since the introduction of CGI scripts, which means longer than Zope has its current name. [...] The idiom '/'+absolute_url(1) to get the path part of an object's URL is *very* common, and as luck will have it *works absolutely fine* as long as inside-out hosting is not present. So this error usually goes undetected and creeps all over people's code. I'd be willing to bet that it is possible to break other packages like, say, Plone simply by changing Vhost configs as well ;-). Note that this is one of my main points: It will be of little use to document usage of BASEPATH1+absolute_url(1) when '/'+absolute_url(1) appears to work (until it is far too late). I can see why you think the API should be changed. But do you really think it is the Right Thing to break existing products of people who read the API documentation and tested their products carefully to fix the products of people who trusted their intuition? Cheers, Yuppie ___ 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] Re: Heads up: about to merge new-style ExtensionClass and ZODB 3.3 into Zope 2 head
Dieter Maurer wrote: I worked a bit with ZopeHead. Required CMF patches attached. Thanks! Based on your patches I made a checkin to CMF HEAD. Cheers, Yuppie ___ 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] Re: Zope Head (2.8) breaks refresh
Jeremy Hylton wrote: @@ -158,8 +158,6 @@ -self._reader = ConnectionObjectReader(self, self._cache, - self._db._classFactory) @@ -168,6 +166,8 @@ +self._reader = ConnectionObjectReader(self, self._cache, + self._db._classFactory) Is there any difference between these two execept for whitespace? Line numbers? HTH, Yuppie ___ 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] Zope-2.7.0-b3-win32.exe not beta 3?
Hi! I'm a bit confused: Can anybody confirm that the Windows installer at http://zope.org/Products/Zope/2.7.0b3/2.7.0b3/Zope-2.7.0-b3-win32.exe contains beta 2 code? I first thought the Version number visible in the Control Panel wasn't updated, but now I stumbled over files that don't have the beta 3 fixes. Cheers, Yuppie ___ 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] Zope 2.7.0 b3 regressions
Hi! Migrating a CMF Site from Zope 2.6 to Zope 2.7.0 b3, I stumbled over these two Zope 2.7 issues: 1.) absolute_url(relative=1) behaves different -- 'relative' was changed from 'relative to site object' to 'relative to server root'. This is an API change and breaks Products like CMF. See http://zope.org/Collectors/Zope/809 I propose to revert this change. 2.) reindexIndex not 100% backwards compatible -- CMF's CatalogTool inherits from ZCatalog and overrides catalog_object. Zope's reindexIndex fails because CMF doesn't implement the new catalog_object API. See http://zope.org/Collectors/Zope/1134 I propose to add a capability check in reindexIndex. I'd volunteer to fix these issues in CVS as proposed, but maybe the people who made these changes still feel responsible for their code or there are objections regarding the proposed fixes. Any feedback is welcome. Cheers, Yuppie ___ 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] Re: Zope 2.7.0 b3 regressions
Hi! Chris McDonough wrote: Eep. Maybe CMF's overridden catalog should just be given a reindexIndex method instead of doing a capability check in Zope? More broadly, is it worth embedding the capabilities check (which can never, ever go away) into Zope itself or would it be better to change CMF to deal with the API change? Why can't the capabilities check go away in a future release? We could add a deprecation warning in reindexIndex in case it detects the old API. And of course CMF has to implement the new API. This is on the todo list: http://collector.zope.org/CMF/206 But is it worth to have a CMF 1.4.3 release just to fix this issue? Cheers, Yuppie ___ 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] Re: Zope 2.7.0 b3 regressions
Chris McDonough wrote: On Wed, 2003-12-03 at 07:33, Yuppie wrote: But is it worth to have a CMF 1.4.3 release just to fix this issue? Probably not, at least if your Zope checkin mentions the reason for the capabilities test and the deprecation warning and maybe the earliest date after which the capabilities check could be removed. It would be good to put this in the code itself, so we know why the capabilities check exists next year when reading the code... does that make sense to you? Sounds good. I'll make the Zope checkin regarding this issue within the next days. Yuppie ___ 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] Re: Zope 2.7.0 b3 regressions
Hi Stefan! Stefan H. Holek wrote: No, no and 3 times no! The fix was done by Evan and is CORRECT. absolute_url () does not (and should not!) know anything about CMF or portals or whatever else! 'relative to site object' is quoted from the API documentation of absolute_url(), see http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixB.stx. 'site object' in this context is the Zope application object and has nothing to do with a CMF Site or whatever else. It MUST however return correct results in all possible VH situations and this is what the fix addresses. Yes. But the correct result is what the API documentation defines. To get what you want you have to add BASEPATH1 defined as the externally visible path to the root Zope folder alias 'Zope application object' alias 'site object'. Look for example at OFS/dtml/main.dtml The real problem is - and this is stated in the original report - that absolute_url(1) did return WRONG RESULTS when inside-out vhosting was in use. This has bitten me on several occasions when customers deployed their sites with the CMF portal NOT living in the root of the vhost (as opposed to the root of Zope) and SERIOUS breakage occurred all over their sites. That's exactly the scenario where I discovered the API change. But it didn't fix anything, it broke at least the icon paths. Cheers, Yuppie ___ 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] Re: Zope 2.7.0 b3 regressions
Hi Lennart! Lennart Regebro wrote: def getVirtualRoot(self): [...] def getVirtualPath(self): How are these related to URLPATHn, BASEPATHn? I'm to lazy to figure it out myself;) Quick, brutal, efficient, and usually dead wrong. That's me. :-) //Lennart Quick? http://mail.zope.org/pipermail/zope-dev/2001-December/014601.html Please be careful with method names that might already be in use in some products. Google says Silva uses a getVirtualRoot() method. Why not using REQUEST variables? Cheers, Yuppie ___ 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] virtual hosting variables [was: Re: Zope 2.7.0 b3 regressions]
Evan Simpson wrote: Lennart Regebro wrote: I will check this into head this evening, and unless people scream tomorrow I will check it into the 2.7 branch. Please hold off. I've been meaning to revisit this for a while, and I have a bit of time to do so today and tomorrow. Also, virtual hosting is properly the domain of the request object, not the object being traversed. This is why the modified absolute_url() uses REQUEST.physicalPathToURL. BTW: I'm missing a REQUEST variable that represents the URL requested by the browser. 'PATH_INFO' doesn't show the virtual URL: '/VirtualHostBase/http/example.org:80/VirtualHostRoot/_vh_test/path/to/object' 'URL' might be changed by __before_publishing_traverse__ or __browser_default__: 'http://example.org/test/path/to/object/index_html/view' So I think it would be great if VHM would add a variable like 'REQUESTED_URL' (should have a better name) that isn't further modified on traversal. 'http://example.org/test/path/to/object' Just my 2 cents. Cheers, Yuppie ___ 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] Re: Zope 2.7.0 b3 regressions
Hi Evan! Evan Simpson wrote: Gotcha. Grepping Zope's source and the Products I had to hand showed only one use of absolute_url(1), in Draft.py, so I hoped that making the implementation sane wouldn't affect too much. Looking at the 1.4 branch of CMF, I see it in three places: 1. DiscussionTool.py uses it when looking up replies. This looks like a non-issue for new or properly converted discussions in 1.4. 2. SkinsTool.py uses it to construct skin cookies. 3. Any caller of URLTool that passes 'relative=1' to it. I can only find one of these, namely getIcon() in DynamicType.py. Is #3 likely to be the cause of the problem you're seeing? Can you be more specific about the circumstances of the problem? Yes. getIcon() is the cause of the problem I see: To access the ZMI I use this Apache rule: ProxyPass /zope27 http://localhost:8080/VirtualHostBase/http/example.org:80/VirtualHostRoot/_vh_zope27 getIcon() for a folder in myCMFSite returns 'zope27/myCMFSite/folder_icon.gif' (was 'myCMFSite/folder_icon.gif' in Zope 2.6) OFS/dtml/main.dtml adds BASEPATH1, so the URL is '/zope27/zope27/myCMFSite/folder_icon.gif' (would be '/zope27/myCMFSite/folder_icon.gif' in Zope 2.6) Zope doesn't know anything about the name 'zope27' and returns 'Resource not found'. The icon URLs are also broken inside the CMF interface, so we would need a CMF 1.4.3 release to get this working with Zope 2.7. Grepping the products on my disk I found some files using absolute_url(1), especially in CMFDeployment. I have no idea if your change fixes or breaks these products. Please let me know if you need further information. Cheers, Yuppie ___ 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] Re: Heads up: about to merge new-style ExtensionClass and ZODB 3.3 into Zope 2 head
Hi Jim! Jim Fulton wrote: I tested CMF with Zope HEAD. 1.) from ZODB import Persistent, PersistentMapping doesn't work anymore 2.) assignment to class dictionaries doesn't work anymore These two are now fixed in CMF HEAD. So whoever wants to have a look at the other issues: Tests and Zope are running again with CMF installed. 3.) 'rebinding by assignment' doesn't work anymore [...] This is consistent with standard Python behavior: [...] So I'm inclined to consider the new behavior correct. Correct or not: This is a backwards compatibility issue. I also found this one: http://localhost:8080/Control_Panel/Database/main/manage_main unbound method db_name() must be called with ApplicationManager instance as first argument (got nothing instead) You already didn't switch to the new mro to make migration easier. If it is possible to give newstyle ExtensionClasses the old rebinding behavior I'd vote for that. If not, people need some advice how to update their products: - How do I find code depending on the old behavior? - How do I fix that code? (I know I can copy 'n' paste the code I want to reuse from other classes, but is there a better way to reuse code without subclassing?) 4.) some objects publishable in Zope 2.7 aren't publishable anymore Can you give any specifics? Zope Core: http://localhost:8080/temp_folder http://localhost:8080/Control_Panel/DavLocks CMF: http://localhost:8080/myCMFSite/portal_skins/zpt_generic http://localhost:8080/myCMFSite/portal_workflow/default_workflow No big deal to add docstrings, but what's the policy change? For better or worse, it has always been policy not to publish objects without non-empty doc strings. That's what I thought. But it seems like Zope 2.7 doesn't catch them all. Cheers, Yuppie ___ 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] Re: Heads up: about to merge new-style ExtensionClass and ZODB 3.3 into Zope 2 head
Jim Fulton wrote: Done! Hi Jim! Here some feedback regarding your checkin. I tested CMF with Zope HEAD. These are the issues I ran into: 1.) from ZODB import Persistent, PersistentMapping doesn't work anymore Maybe Zope 2.7 should have a deprecation warning? 2.) assignment to class dictionaries doesn't work anymore I copied your fix for ZopePageTemplate to FSPageTemplate. Now Zope started again. 3.) 'rebinding by assignment' doesn't work anymore With oldstyle ExtensionClasses you were able to rebind methods by assignment, without subclassing from the class that defines the method. CMFCore/FSPageTemplate.py seems to be a good use case for that feature: class FSPageTemplate(FSObject, Script, PageTemplate): pt_getContext = ZopePageTemplate.pt_getContext This works fine with Zope 2.7, but raises an error with Zope HEAD: TypeError: unbound method pt_getContext() must be called with ZopePageTemplate instance as first argument (got nothing instead) I fixed this one and now a CMF Site seems to work, but I'm afraid this pattern is used in other places. The unittests show this: TypeError: unbound method manage_addPortalFolder() must be called with PortalFolder instance as first argument (got str instance instead) 4.) some objects publishable in Zope 2.7 aren't publishable anymore No big deal to add docstrings, but what's the policy change? 5.) other issues I was not able to track this error down, but maybe you've got an idea what's going wrong here? http://localhost:8080/myCMFSite/portal_types/Document/manage_propertiesForm Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.CMFCore.utils, line 350, in manage_propertiesForm Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 281, in _bindAndExec Module Shared.DC.Scripts.Bindings, line 1, in ? Module Shared.DC.Scripts.Bindings, line 218, in _getContext AttributeError: aq_parent Cheers, Yuppie ___ 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] Re: Zope 2.7 b3 problem with reindexing catalog
Dieter Maurer wrote: robert wrote at 2003-11-24 05:32 +0100: Traceback (innermost last): * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Products.ZCatalog.ZCatalog, line 474, in manage_reindexIndex * Module Products.ZCatalog.ZCatalog, line 459, in reindexIndex TypeError: catalog_object() got an unexpected keyword argument 'update_metadata' update_metadata is a new keyword argument introduced recently (to fix a bug in Zope 2.6.2). Apparently, you have hit a bug in ZCatalog: While reindexIndex already uses the new argument, catalog_object does not yet support it. Yes. CMF's CatalogTool inherits from ZCatalog and overrides catalog_object. Robert, please report this to the Zope and the CMF Collector: - Zope's ZCatalog should have a capability check in reindexIndex. (Zope-2_6-branch, Zope-2_7-branch and HEAD) - CMF's CatalogTool should implement the new Interface. Cheers, Yuppie ___ 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] Re: Zope 2.7 b3 problem with reindexing catalog
robert wrote: I opened an issue in the Zope collector but I am to dumb to find the CMF collector. If somebody please points me to it. http://collector.zope.org/CMF or http://zope.org/Collectors/CMF Yuppie ___ 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] Re: CMF: _getViewFor() problem
Mark Wilson wrote: I'm attempting to use Plone with CMF 1.4.2 and Zope 2.7b2. I'm getting errors [...] Any info gratefully received. Thanks 1.) This list is for development *of* Zope, not *with* Zope. 2.) See http://plone.org/development/lists for Plone lists. 3.) You know Plone 1.x requires CMF 1.3.3, Plone 2.x requires CMF 1.4.2? 4.) If you still want to modify Plone 1.x: Search plone-users archives at gmane for _getViewFor. HTH, Yuppie ___ 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] Re: manage_workspace changes
Hi! Dieter Maurer wrote: Due to a bug in the the condition, however, it redirected for all methods unless they started with a / (reported as a bug in the Zope mailing list). I fixed the condition (patch to collector 1058). Unfortunately, returning getattr(self,method)(self,REQUEST) requires the method to be DTML like and breaks if this is not the case. I now think it is best to *always use the redirect and never return the method. My code now looks like: [...] Thanks! I don't have the time to look into the details. Meanwhile Andreas also stumbled over this issue (with different symptoms, see http://article.gmane.org/gmane.comp.web.zope.plone.user/8507 ) and reverted the manage_workspace changes in CVS. Don't know - if someone checks in your new patch soon (I guess there should be unittests that catch the broken use cases so any future checkins are checked against these use cases.) - if collector #1058 should be reopened - if Zope is currently more broken than before because parts of your patch are still in CVS Cheers, Yuppie ___ 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] manage_workspace changes
Hi! As also mentioned here http://mail.zope.org/pipermail/cmf-checkins/2003-October/003702.html some CMF tool tabs are broken if used with a current Zope-2_6-branch checkout. I didn't spend much time to find out what's really going on here, so I might be missing something. But it looks like the fix for http://collector.zope.org/Zope/1058 (regarding an PropertySheets issue) causes this bug. Can anybody confirm this? Or has anybody an other idea which recent change could cause the problem? Was it really necessary to break backwards compatibility? Thanks, Yuppie ___ 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] Re: catalogObject changes (Zope-2_6-branch)
Hi! Chris McDonough wrote: Option 1: Add an update_metadata flag to the catalogObject method with a default of True on all branches. Option 2: Do nothing, but add the updateMetadata method to the ZCatalog interface. Option 1 would only take effect when 2.6.3 was released (if ever) and 2.7 final would have the new flag. Because since the behavior change has already been released in 2.6.2, it might be better to do option 2 and fix the places in CMF/SilvaMetadata that specify indexes, leaving it the way it is. I agree backwards compatibilty is broken anyway. Whatever the solution is, products using the idxs argument for metadata changes have to be changed to work with 2.6.2. Regarding migration, I agree option 2 would be better. Regarding the interface, I still prefer option 1 or even option 1 *and* 2. The fact that zcat.catalog_object(obj) does update metadata while zcat.catalog_object(obj, idxs=zcat.indexes()) doesn't, isn't intuitive at all. At least this difference has to be mentioned in the interface definition. Just my 2 cents. I can live with both options. Cheers, Yuppie ___ 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] Re: catalogObject changes (Zope-2_6-branch)
Hi Chris! Chris McDonough wrote: The system is making the assumption that if you update indexes individually, you know what you're doing. Passing an index name into catalogObject was always meant to do as much or as little work as you specified with respect to the names of the indexes; it was only by mistake that metadata got updated when indexes were specified. The new (correct) behavior may break some applications that depended on the bug, and I'm sorry it broke yours, but it was indeed a bug. Thanks for clarifying this! Now I understand why you changed it this way. But I still don't agree you fixed a bug. From my point of view this was an API change. 1.) The interface (IZCatalog.py) a.) If provided, idxs specifies the names of indexes to update. No different behavior regarding metadata update is mentioned. b.) There is no other interface method to update metadata, so catalog_object is responsible for keeping metadata in sync. 2.) The use cases a.) Change of many object attributes or big attributes like 'body'. Everything should be updated, works like before. b.) Dieter described this already: The idxs argument is often provided to update only special indexes: e.g. workflow indexes or AllowedRolesAndUsers and when you update selected indexes from the Indexes tab. In these cases, it is often not necessary to update the Metadata. c.) Change of metadata. Before you 'fixed' catalog_object, it was possible to edit and reindex metadata like Description without reindexing the whole PDF / Word body of a file. Now this expensive task has to be perfomed after each metadata change. 3.) The existing code a.) CMF. Not badly broken, but the metadata of new content items is now wrong. This line in TypesTool.py doesn't work as expected: ob.reindexObject(idxs=['portal_type', 'Type']) b.) SilvaMetadata. The reindex code seems to be broken: http://cvs.infrae.com/SilvaMetadata/Binding.py?rev=1.39content-type=text/vnd.viewcvs-markup Adding an 'update_metadata' flag would have been backwards compatible and useful for each use case. And, doh, yes, I need to forward-port the fix to the 2.7 branch and the HEAD. :-( I saw you were working on sunday. At least this time you mentioned the change in CHANGES.txt... Cheers, Yuppie ___ 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] catalogObject changes (Zope-2_6-branch)
Hi! Yesterday I spent some hours tracking down why catalog Metadata and catalog Indexes are getting out of sync in my CMF Site. I found that checkin http://cvs.zope.org/Zope/lib/python/Products/ZCatalog/Catalog.py.diff?r1=1.98.6.10r2=1.98.6.11 including this new condition code if not idxs: # if the caller specifies that we should update only a # specific set of indexes, we don't do a metadata update. self.updateMetadata(object, uid) /code Could anybody tell me what's the rationale behind that checkin? - it breaks backwards compatibility - it's only in Zope-2_6-branch, not in Zope-2_7-branch or HEAD - I can't see what this 'if' is good for anyway Cheers, Yuppie ___ 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] Re: CVS: Zope/lib/python/TAL - TALGenerator.py:1.65
Hi! Chris McDonough wrote: Hmm. Without this fix, many CMFDefault (and possibly CMFCore) skins don't work. Is there a way to fix the offending CMF skins so that it works under Zope versions both with this fix and without (so we don't need two versions of CMF)? More importantly, is anyone willing to actually do this work? CMFCore has no skins. CMFDefault is the only product in cvs.zope.org:/cvs-repository/CMF using i18n. CMFDefault has just one template using this pattern: index_html_utils.html uses i18n:attributes=alt title So it would not be much work to change CMF. I'm not talking about third party products building on top of CMF. Plone was already discussed, I don't know what's the case with other products. What about backporting the i18n fix to Zope 2.6.2 ? Using CMF / Plone with i18n support requires Zope 2.6.0 anyway. Maybe we could force people updating CMF / Plone also to update Zope to 2.6.2. This way CMF / Plone could switch to the new spec. Just my 2 cents. Yuppie ___ 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] CHANGES.txt policy
Hi! This guideline http://dev.zope.org/CVS/ZopeDevelopmentProcess is very useful, but there are at least 2 questions it doesn't answer: 1.) How does it work with 2 release branches? (currently there are Zope-2_6-branch and Zope-2_7-branch) 2.) How to note the fix in the CHANGES.txt on the trunk if you want? looking at current practise: Since Zope-2_7-branch was tagged, there were two changes affecting all 3 branches: Collector #959/#514: CHANGES.txt Zope-2_6-branch: note in 2.6.2 beta 4 section CHANGES.txt Zope-2_7-branch: - CHANGES.txtHEAD: - Collector #953: CHANGES.txt Zope-2_6-branch: note in 2.6.2 beta 3 section CHANGES.txt Zope-2_7-branch: note in 2.7.0a2 section CHANGES.txtHEAD: note in HEAD only section HEAD only is definitely not true. Should HEAD's CHANGES.txt have a 2.6.2 beta 3 section? Any thoughts? What's the Right Way to do it? Thanks, Yuppie ___ 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] Re: Ordered Folder again
Hi! Florent Guillaume wrote: But FWIW, note that in Nuxeo CPS we've always been using a monkey patch that added ordering to Folder without any problem. (http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/OrderedFolderSupportPatch/) CPS doesn't subclass from PortalFolder? If CPS would have its own class like PloneFolder in Plone, you could just mix in OrderSupport. But maybe CMFCore.PortalFolder should mix in OrderSupport? Would that help to solve your problem? Cheers, Yuppie ___ 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] Re: Ordered Folder again
Hi Florent! Florent Guillaume wrote: CPS doesn't subclass from PortalFolder? If CPS would have its own class like PloneFolder in Plone, you could just mix in OrderSupport. We could, except that - we want to be useable with standard CMF objects Was just asking. I think you're doing the Right Thing. - everybody wants ordering Well, you want ordering, I want ordering, many other people want it. But maybe it's a special content management need. But maybe CMFCore.PortalFolder should mix in OrderSupport? Would that help to solve your problem? That's definitely a thing that would be useful, but I still stand by my proposal. Wish you good luck! I'm not very happy with the changes you propose, but if it helps to convince people ... Cheers, Yuppie ___ 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 )
