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 

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 
... 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
Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to