[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
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? On Wed, 2003-12-03 at 06:53, Yuppie wrote: 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] Zope 2.7.0 b3 regressions
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. +1 from me. The original proposal has been to implement a separate method for this; maybe this should be done insetad. I thought the point to break backwards compatibility and to get rid of all the old cruft has been choosen to be Zope3, not Zope2.7, isn't it ? ;-) Cheers, Clemens ___ 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
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: http://collector.zope.org/CMF/206 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? - C ___ 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 )
Re: [Zope-dev] Zope 2.7.0 b3 regressions
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 http://zope.org/Collectors/Zope/809
I propose to revert this change.
+1.
I added a comment to the Issue, and are copying it here FYI:
There is no reason to change absolute_url. If you use CMF, there is the
portal_url tool, which could need some enhancing, btw, and if not, you need
to make your own set of methods. Methods you sooner or later will need are
(the exact naming is optional):
virtualRootPath(ob): Returns the path to the virtual root. For example: ('',
'mysite.com')
physicalPath(ob): Returns the full path to the object. For example: ('',
'mysite.com', 'path', 'to', 'object')
//Note: This already exists as obj.getPhysicalPath()...
virtalPath(ob): Returns the path from the virtual root. For example: ('',
'path', 'to', 'object') (Note that it starts with a '')
path2url(path): For the above paths returns '/mysite.com',
'/mysite.com/path/to/object' and '/path/to/object' respectively.
After you have these, you can forget about absolute_url. :)
I have yet encountered a specific need to return
'http://www.mysite.com/anything' because the browser will typically add
that automatically anyway when you return '/anything'.
These methods SHOULD really be a part of the VirtualHostMonster, but they
aren't. People are welcome to fix this. :-) Since the VirtualHostMonster
determines the virtual root dynamically per request, I don't know how to
implement virtualRootPath and virtualPath... I guess you would need to get
the virtual root from the request, somehow. You'll still end up with the
situation that you want the virtual root for objects that are under other
virtual roots that the one the current request is using, but that is an
unsolvable problem with the current VirtualHostMonster.
//Lennart
___
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 )
Re: [Zope-dev] Zope 2.7.0 b3 regressions
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 my attempt to correct the situation by adding a new method - that was nonsense. 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. 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. So -100 for unfixing things you don't seem to properly understand. Stefan --On Mittwoch, 03. Dezember 2003 12:53 +0100 Yuppie [EMAIL PROTECTED] wrote: 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. -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/ ___ 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 )
Re: [Zope-dev] Zope 2.7.0 b3 regressions
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 have to know about portals is correct. The portal_url tool was specifically created to provide you with paths and URLs that are relevant to the CMF site - if there are any problems the URLTool needs to be extended or fixed to address that. jens smime.p7s Description: S/MIME cryptographic signature ___ 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 )
Re: [Zope-dev] DateTime stftime and TAI based timezone is broken or is it?
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 even the datetime python modules punt in this
regard. What I'm currious to know is how this caused problems for
you, or your clients. I'd like to avoid those problems myself if I
can help it.
My legacy site has a lot of dtml-var somedatetimeobject fmt=%a %b %d
this writes out the wrong day, because somedatetimeobject is just like you show above.
Also, I get different results instantiating a DateTime object with a string, vs. parts
DateTime(y,m,d,h,m,s) vs. DateTime('-MM-DD HH:MM:SS')
Why can't Zope just dynamically load the tzfile data as appropriate from the system if
it
can?
--
Brad Clements,[EMAIL PROTECTED] (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
http://www.wecanstopspam.org/ AOL-IM: BKClements
___
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 )
Re: [Zope-dev] Zope 2.7.0 b3 regressions
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 following new
methods on Traversable:
getVirtualRoot__roles__=None # Public
def getVirtualRoot(self):
try:
req = self.REQUEST
rpp = req.get('VirtualRootPhysicalPath', ('',))
return rpp
except AttributeError:
return ('',)
getVirtualPath__roles__=None # Public
def getVirtualPath(self):
root = self.getVirtualRoot()[1:] # No point in including the root
path = self.getPhysicalPath()[1:]
for each in root:
if path[0] == each:
path = path[1:]
else:
break
# And then we add the root again:
return ('',) + path
path2url__roles__=None # Public
def path2url(self, path):
return '/'.join(path)
I will check this into head this evening, and unless people scream tomorrow
I will check it into the 2.7 branch. With the above methods there will be
little use of absolute_url, and you will be able to rely on the answers.
Portal_url may need to rely on these methods, I'll look into that later.
Quick, brutal, efficient, and usually dead wrong. That's me. :-)
//Lennart
___
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] Re: Zope 2.7.0 b3 regressions
[...] 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 conflict here. But thanks for checking this, anyway. :) Cheers, Clemens ___ 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
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. 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 containment path, possibly modified by virtual hosting. If the optional 'relative' argument is true, only return the path portion of the URL.''' Relative in this context refers to the concept of a relative path as used in rfc1808, not to a relationship with a Zope object. It is meant for use in situations such as redirection to a secure page from an insecure one (eg. 'https://example.com' + target.absolute_url(1)) where you would otherwise have to generate the complete URL and then break it apart. Current behavior looks like this: http://localhost:8080/temp_folder/test absolute_url( ): http://localhost:8180/temp_folder/test absolute_url(1): temp_folder/test http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/test absolute_url( ): http://www.example.com/temp_folder/test absolute_url(1): temp_folder/test http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/test absolute_url( ): http://www.example.com/test absolute_url(1): test http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/_vh_foo/test absolute_url( ): http://www.example.com/foo/test absolute_url(1): foo/test This is entirely consistent, predictable, and easy to explain. The problem you are encountering is almost certainly due to a use of absolute_url where it shouldn't be used, or is used incorrectly. Cheers, Evan @ 4-am ___ 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
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 variables?
Because it would be wrong, ugly, inconsistent with GetPhysicalPath and/or
complicated to implement? :-)
To explain them I'll use Evans examples (without testing so I could be
wrong):
http://localhost:8080/temp_folder/test
getVirtualRoot(): ('',)
getVirtualPath(): ('', 'temp_folder', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/test
getVirtualRoot(): ('',)
getVirtualPath(): ('', 'temp_folder', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/test
getVirtualRoot(): ('', 'temp_folder')
getVirtualPath(): ('', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/_vh_foo/test
getVirtualRoot(): ('', 'temp_folder')
getVirtualPath(): ('', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')
I think :-)
___
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 )
Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions
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 conflict here. But thanks for checking this, anyway. :) And even if it was, your implementation would reasonably override Traversable, and there would be no breakage... ___ 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 )
Re: [Zope-dev] virtual hosting variables [was: Re: Zope 2.7.0 b3 regressions]
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 recently where using traverse_subpath in a python script screwed
up CookieCrumbler (which uses REQUEST.URL to determine where it should redirect).
Basically it ate the end of the URL value so the login form redirected to the wrong
place.
The evil hack fix was actually a REQUEST.set('URL', ...), in the python script before
any unauthorized errors could be raised. Perhaps it should be called ACTUAL_URL or
ORIGINAL_URL. This would be the thing that CookieCrumber would redirect to...
-Casey
___
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 )
Re: [Zope-dev] Zope 2.7.0 b3 regressions
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 and this is what the fix addresses. But, when absolute_url(1) behaves as Yuppie describes, it does not behave correct. Let's look at it from a semantic point of view: HTTP knows two kinds of absolute URL references, univeral absolute URLs (containing the protocol and the server) and server relative absolute URL (starting with a /). The first notion is supported by absolute_url(). For unknown reasons, absolute_url(1) only almost realizes the second notion (it lacks the leading /). But, we became familiar with this deficiency. When you accept that absolute_url(1) should come near to the notion of server relative absolute URL, then it *must* return an URL with respect to the currently active site root. Otherwise, the browser using this URL will interpret it wrongly. It may still work due to acquisition, but this is more by accident. Thus, I agree with Yuppie. If absolute_url(1) behaves as he describes, then it is wrong and there is no longer an easy way to implement the notion of server relative absolute URL reference. -- Dieter ___ 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
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 changed the API in a way that is not backwards compatible. I encountered the problem with a plain new CMF Site. 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? Cheers, Evan @ 4-am ___ 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 )
