[Twisted-web] url.URL.fromRequest gives unexpected behaviour

Matt Goodall matt at pollenation.net
Wed Sep 15 10:53:55 MDT 2004


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 at pollenation.net
 /  \__/  \    t: +44 (0)113 2252500
 \__/  \__/
 /  \          Any views expressed are my own and do not necessarily
 \__/          reflect the views of my employer.




More information about the Twisted-web mailing list