[Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
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

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Chris McDonough
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?

[Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Clemens Robbenhaar
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

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
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

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Chris McDonough
On Wed, 2003-12-03 at 07:33, Yuppie wrote: 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. That's true. And of course CMF has to implement the new API. This is on the todo list:

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
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

Re: [Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Lennart Regebro
From: Yuppie [EMAIL PROTECTED] 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

Re: [Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Stefan H. Holek
Yuppie! 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! It MUST however return correct results in all possible VH situations and this is what the fix addresses. Please forget about

Re: [Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Jens Vagelpohl
If you need anything CMF specific use the portal_url tool. I do not see why a basic infrastructure method like absolute_url() should know anything about portals at all. I have to admit I did not look deeply, but Stefan's notion that absolute_url is a basic infrastructure method that should not

Re: [Zope-dev] DateTime stftime and TAI based timezone is broken or is it?

2003-12-03 Thread Brad Clements
On 2 Dec 2003 at 13:39, Jamie Heilman wrote: y = DateTime.DateTime(dx) y DateTime('2003/12/01') y.strftime(%a %b. %d) 'Sun Nov. 30' y.strftime(%a %b %d %H:%M:%S) 'Sun Nov 30 23:59:38' Lovely. Its always bugged me that DateTime carried all its own zone information, but I guess

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
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

Re: [Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Lennart Regebro
Please excuse my impatiance, but sometimes I just think it's obvious that I'm right, and that people don't listen. My experience of this is that I'm wrong in at least half of the cases, so that is probably what has happened now too. However, I took a look at the issue, and ended up with the

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
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?

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Clemens Robbenhaar
[...] 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? ... which is defined in an adapter-style class which is not implementing Traversable itself, so there is no

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Evan Simpson
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

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Lennart Regebro
From: Yuppie [EMAIL PROTECTED] Quick? Yeah, yeah. I was fast once I actually did it. :-) Please be careful with method names that might already be in use in some products. Google says Silva uses a getVirtualRoot() method. And EasyPublisher uses all of these already. Why not using REQUEST

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Lennart Regebro
From: Clemens Robbenhaar [EMAIL PROTECTED] Please be careful with method names that might already be in use in some products. Google says Silva uses a getVirtualRoot() method. ... which is defined in an adapter-style class which is not implementing Traversable itself, so there is no

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
Hi Evan! Evan Simpson wrote: Yuppie wrote: 'relative to site object' is quoted from the API documentation of absolute_url() The API documentation is incorrect, and the docstring in the method is correct: '''Return a canonical URL for this object based on its physical

[Zope-dev] virtual hosting variables [was: Re: Zope 2.7.0 b3 regressions]

2003-12-03 Thread Yuppie
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

Re: [Zope-dev] virtual hosting variables [was: Re: Zope 2.7.0 b3 regressions]

2003-12-03 Thread Casey Duncan
On Wed, 03 Dec 2003 20:43:23 +0100 Yuppie [EMAIL PROTECTED] wrote: [snip] 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' +1 I actually had a case

Re: [Zope-dev] Zope 2.7.0 b3 regressions

2003-12-03 Thread Dieter Maurer
Stefan H. Holek wrote at 2003-12-3 15:25 +0100: 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! Right... It MUST however return correct results in all possible VH situations

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Evan Simpson
Yuppie wrote: You introduced that concept in Zope 2.7. The method docstring is part of your change. Before Zope 2.7, absolute_url was defined different, worked different and was used different in products maintained by ZC. [snip] I don't think the old API was better. I'm just saying that you

[Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-03 Thread Yuppie
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.