url.URL.fromRequest gives unexpected behaviour
Hi, URL.fromRequest() currently creates a URL for the path segments that have been resolved so far. That means that creating a URL in locateChild and a rend_* method gives you a different URL. That's unexpected. I think we need more explicit ways of creating a URL to allow for different usecases: URL.fromString(aStr) create a URL from the string. this is already implemented URL.fromRequestURI(aRequest) create a URL that matches the request exactly URL.fromContext(aContext) create a URL for handled path segments. kind of like the url.here overlay but not so lazy. A better name for fromContext might be fromLocation, fromSegment, etc. We can deprecate URL.fromRequest but, until it's removed, make it call fromContext. Cheers, Matt -- __ / \__ Matt Goodall, Pollenation Internet Ltd \__/ \ w: http://www.pollenation.net __/ \__/ e: matt@pollenation.net / \__/ \ t: +44 (0)113 2252500 \__/ \__/ / \ Any views expressed are my own and do not necessarily \__/ reflect the views of my employer.
On Sep 8, 2004, at 7:35 AM, Matt Goodall wrote:
Hi,
URL.fromRequest() currently creates a URL for the path segments that have been resolved so far. That means that creating a URL in locateChild and a rend_* method gives you a different URL. That's unexpected.
Hi, sorry for not responding for so long. This is actually intentional behavior and is expected -- but so much of the url module seems surprising to other people that I think we have to stop and seriously revisit it.
I think we need more explicit ways of creating a URL to allow for different usecases:
URL.fromString(aStr) create a URL from the string. this is already implemented
URL.fromRequestURI(aRequest) create a URL that matches the request exactly
This would always return a URL object which could reproduce the URL used to make the current request. This would be a good thing. But what exactly does the URI at the end of the method name indicate?
URL.fromContext(aContext) create a URL for handled path segments. kind of like the url.here overlay but not so lazy.
Recently, I changed the way keeping track of the current segments works by remembering ICurrentSegments and IRemainingSegments in the context. Since each Page gets it's own Context object, URL.fromContext could be explicitly given a Context object which is at the level for which you want the url generated. For example, if you are requesting the url /foo/bar/baz but you want a URL object for just /foo, you could find the Context object representing this and do URL.fromContext with it. (You could find it in the appropriate locateChild, or you could find it by climbing the Context .parent chain). This would be a nice way to build breadcrumb trails.
A better name for fromContext might be fromLocation, fromSegment, etc.
We can deprecate URL.fromRequest but, until it's removed, make it call fromContext.
I don't think we should deprecate fromRequest, just change what it does semantically. I don't think anyone was relying on the old behavior, anyway. dp
On Tue, 2004-09-14 at 15:03, Donovan Preston wrote:
On Sep 8, 2004, at 7:35 AM, Matt Goodall wrote:
Hi,
URL.fromRequest() currently creates a URL for the path segments that have been resolved so far. That means that creating a URL in locateChild and a rend_* method gives you a different URL. That's unexpected.
Hi, sorry for not responding for so long.
No problem, I'm busy too ;-)
This is actually intentional behavior and is expected -- but so much of the url module seems surprising to other people that I think we have to stop and seriously revisit it.
I'd been happily using it and only started questioning the behaviour of fromRequest() when I was explaining it someone else and they said, "but that's not the URL that's been requested". In general I think the url module is wonderful. There are a couple of ambiguities and surprises, that's all.
I think we need more explicit ways of creating a URL to allow for different usecases:
URL.fromString(aStr) create a URL from the string. this is already implemented
URL.fromRequestURI(aRequest) create a URL that matches the request exactly
This would always return a URL object which could reproduce the URL used to make the current request. This would be a good thing. But what exactly does the URI at the end of the method name indicate?
The "URI" bit was to make it explicit and would allow us to deprecate the existing method. It may not be needed.
URL.fromContext(aContext) create a URL for handled path segments. kind of like the url.here overlay but not so lazy.
Recently, I changed the way keeping track of the current segments works by remembering ICurrentSegments and IRemainingSegments in the context. Since each Page gets it's own Context object, URL.fromContext could be explicitly given a Context object which is at the level for which you want the url generated. For example, if you are requesting the url /foo/bar/baz but you want a URL object for just /foo, you could find the Context object representing this and do URL.fromContext with it. (You could find it in the appropriate locateChild, or you could find it by climbing the Context .parent chain). This would be a nice way to build breadcrumb trails.
A better name for fromContext might be fromLocation, fromSegment, etc.
We can deprecate URL.fromRequest but, until it's removed, make it call fromContext.
I don't think we should deprecate fromRequest, just change what it does semantically. I don't think anyone was relying on the old behavior, anyway.
I am! ;-). I don't really mind if it changes though, I can update my code easily enough. Cheers, Matt -- __ / \__ Matt Goodall, Pollenation Internet Ltd \__/ \ w: http://www.pollenation.net __/ \__/ e: matt@pollenation.net / \__/ \ t: +44 (0)113 2252500 \__/ \__/ / \ Any views expressed are my own and do not necessarily \__/ reflect the views of my employer.
participants (2)
-
Donovan Preston -
Matt Goodall