Chris Withers wrote:

Since these are both confused, long standing feature requests, what I'd recommend instead is writing a mail to this list explaining exactly what the problem is that you're having, the changes you would like made, and why you'd likee them made. You could even give it a nice descriptive subject line :-)

I suspect there's a solution that doesn't involve any changes to Zope lurking there since this funcionality, as best I can understand it, seems to be extremely rarely requested.

The only reason i had for writing this crap code listed in issue #1252 was the requirement to generate urls inside zope which are exactly the same as the url the user entered into the browser. VIRTUAL_URL does this as required, but absolute_url or all other builtin zope methods i am aware of do not. Only thing which is required _no matter of what conditions_ is a anytime available method/request attribute which holds the url the user actually entered and works in both virtualhosting and non virtualhosting conditions. Right now the only way to do this is something like this: <a tal:define="url request/VIRTUAL_URL|string:${request/SERVER_URL}${request/PATH_TRANSLATED}" tal:attributes="href string:${url}#someContent"></a> So having VIRTUAL_URL anytime available would help alot. Cheers, Simon

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote: | It appears there are a LOT of variables already available, one of which | may do what you want. This is beginning to sound like a documentation | problem rather than a "we need more methodz" problem. Thats right there are a lot of variables methods already. But as far as i remember i looked at the problem a couple of months ago already and wasnt able to find a better solution than the one limi posted to the zope-dev list (as shown in #1252). If there is some other way already available, please tell me :) For my point i am fine with the solution posted there, but i agree that it might be worth the pain to find a simple solution. Simon - -- Simon Eisenmann [ mailto:simon@struktur.de ] [ struktur AG | Junghansstraße 5 | 70469 Stuttgart ] [ T. +49.711.896656.68 | F.+49.711.89665610 ] [ http://www.struktur.de | mailto:info@struktur.de ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBKwFOcKXkdvrBGTARAvyQAJ0cKMADEa2oq9tbk2MAYeS4+Z1gygCePAww 89DbZtcLX4B+73XkMC9YMJE= =VFhZ -----END PGP SIGNATURE-----

Hi! Paul Winkler wrote:

absolute_url

- containment only, does not include contextual elements from the client's URL, that's the whole point of this method :-)

absolute_url(relative=1) - same as absolute_url, and not usable in some VHM situations.

absolute_url_path - is usable with VHM, but still containment only.

virtual_url_path - is usable with VHM, but still containment only.

getPhysicalPath - containment only, not compatible with VHM at all and should NEVER be used for URLs.

getPhysicalRoot - returns the zope app root, not relevant to this discussion.

request/URLx - close, but no cigar: leaves out traverse_subpath elements.

request/VIRTUAL_URL - includes context and traverse_subpath elements, but doesn't work if a VHM is not present or is not triggered.

Thanks for that nice overview! Just one additional remark: Besides using traverse_subpath, there is an other reason why request/URLx can get out of sync with the URL requested by the browser: The path might be changed on traversal, using __before_publishing_traverse__ or __browser_default__ hooks. Cheers, Yuppie

On Wed, Aug 25, 2004 at 01:52:26PM +0100, Chris Withers wrote:

Paul Winkler wrote:

...

absolute_url

- containment only, does not include contextual elements from the client's URL, that's the whole point of this method :-)

What do you mean by "contextual elements from the client's URL"

Anything in the acquisition context (i.e. in aq_chain) that is not in the object's physical path. The use case that prompted this thread requires building URLs that include these "contextual elements". Right now there is no clean, simple way to get at that information. This particular bit of information (the actual URL that the client requested) is very often irrelevant, or we'd have dealt with this a long time ago :-) But occasionally it's really handy to know. It's a wheel that people get to occasionally reinvent for no good reason, and while it's not rocket science to get it right, it IS way too easy to get wrong.

...

absolute_url(relative=1) - same as absolute_url, and not usable in some VHM situations.

But what's it for? What change does relative=1 make? Why is it not usuable in some situtations?

relative=1 is the same as virtual_url_path (which it now calls).

...

absolute_url_path - is usable with VHM, but still containment only.

virtual_url_path - is usable with VHM, but still containment only.

Again, what do both of these do?

virtual_url_path replaces absolute_url(relative=1) which IIRC is going to be deprecated because everybody hates the inherent absurdity of it. absolute_url_path includes a leading slash and virtual_url_path does not. absolute_url_path is always safe to use with VHM but virtual_url_path may not be if it really behaves the same as the old absolute_url(relative=1). I don't recall when or why this breaks. I haven't the time to grok it right now. Anyway, neither of them include "contextual elements" as described above. Nor do they give you access to the traverse_subpath. So they do not fit the use case.

...

getPhysicalPath - containment only, not compatible with VHM at all and should NEVER be used for URLs.

?! it certainyl works as inteneded with VHMs, what are you trying to say here?

Yes it works as intended. See the docstring: '''Returns a path (an immutable sequence of strings) that can be used to access this object again later, for example in a copy/paste operation. getPhysicalRoot() and getPhysicalPath() are designed to operate together. ''' This says nothing about URLs because that's not the intended usage. Maybe a warning about this should be added to the docstring to make it explicit. When I said "not compatible with VHM", I should have said "should not be abused for generating URLs as the resulting paths do not take account of virtual hosting." E.g. such a URL does not include "_vh_foo" virtual path elements and it does include the "hidden" path elements that come before VirtualHostRoot. Of course you can use getPhysicalPath to build your URLs if you take care of these VHM issues, but why on earth should you? That's why absolute_url and absolute_url_path exist.

...

request/URLx - close, but no cigar: leaves out traverse_subpath elements.

Really?

Yes, really.

Should it?

Good question! Why the heck doesn't it? Seems counterintuitive to me. While we're on the topic, there's also request/PATH_INFO ... which is not what's wanted because it includes the complete request sent to Zope including all the VHM gunk.

...

request/VIRTUAL_URL - includes context and traverse_subpath elements, but doesn't work if a VHM is not present or is not triggered.

Interesting. What's wrong with just:

python:request.URL+'/'+'/'.join(request.traverse_subpath)+'?'+REQUEST.QUERY_STRING

?

It's a mouthful, and it's non-obvious. And, one nitpick: if traverse_subpath is empty, this idiom adds a spurious trailing slash. I would rather have request/URL include the traverse_subpath. Either that or have request/VIRTUAL_URL always available, as proposed earlier in this thread. -- Paul Winkler http://www.slinkp.com

On Tue, Aug 31, 2004 at 11:09:03AM +0100, Chris Withers wrote:

...

...

...

absolute_url_path - is usable with VHM, but still containment only.

virtual_url_path - is usable with VHM, but still containment only.

Again, what do both of these do?

virtual_url_path replaces absolute_url(relative=1) which IIRC is going to be deprecated because everybody hates the inherent absurdity of it.

but WHAT DOES IT DO?! ;-)

http://collector.zope.org/Zope/809 Or just look at Traversable.py in 2.7.x.

Maybe... How's the API reference code coming? ;-)

The code is not coming, currently. I'm doing an ad-hoc cleanup of the API reference for the 2.7/2.8 Zope Book first.

...

...

...

request/URLx - close, but no cigar: leaves out traverse_subpath elements.

Really?

Yes, really.

...

Should it?

Good question! Why the heck doesn't it? Seems counterintuitive to me.

Indeed. Can we propose this as a change for 2.8? Would sir care to open a collector issue? ;-)

OK. I'll see if i can work up a patch too. Digging into HTTPRequest.get at the moment...

...which doesn't matter one iota to Zope, but does illustrate my point. This kind of URL building is very problem specific, with each person wanting something slightly different. Adding more methodz to cope, or one method with a myriad of options doesn't feel like the right way to go about it to me...

It also illustrates *my* point: This particular use case is very simply stated, I do not agree that it's an edge case, and current solutions are much too subtle and non-obvious. If we leave it to people to re-discover this solution, or document a particular idiom such as yours (where?), the hapless admin who comes across this code for the first time is *still* going to have to look at it and say "what the heck does that do?", and if he doesn't find the particular bit of proposed documentation, there is a good chance he could accidentally break it in for some case. -- Paul Winkler http://www.slinkp.com