On Mon, Jan 5, 2009 at 11:13 AM, Wyatt Baldwin
<[email protected]> wrote:
>> > Another issue with url_for is the handling of query string parameters
>> > using keyword arguments. Currently any extra keyword arguments will be
>> > added to the generated URL as query string, for example:
>>
>> > url_for('/page', arg='val') ==> /page?arg=val
>>
>> > The problem is that you can't use keyword arguments for any of the
>> > argument names reserved by the function, such as "host", "protocol",
>> > etc, for example:
>>
>> > params = { 'arg': 'val', 'host': 'machine' }
>>
>> > url_for('/page', **params)
>>
>> > should return:
>>
>> > /page?arg=val&host=machine
>>
>> > but it treats the "host" key in params as the host name so it actually
>> > returns:
>>
>> Right, the alternative we thought of was forcing all the keyword args
>> destined for Routes to be in a dict passed in, but that obviously
>> makes it a little more annoying to use, though it keeps the arguments
>> separate from the ones url_for itself uses. However, I could see
>> having it strip off arg's with a trailing underscore for use by
>> Routes, such that you'd be able to do:
>> url_for('/page', host_='machine') -> /page?host=machine
>>
>> Would that work?
>
> Personally, I don't like the trailing underscore idea all that much
> (it might be hard to spot and its meaning isn't obvious). I don't have
> a better suggestion right atm though...
The trailing undercore syntax is already implemented for dealing with
Python reserved words.
$ paster shell development.ini
>>> from routes import url_for
>>> from pylons import url
>>> url_for("ABC", print_=1)
'ABC?print_=1'
>>> url("ABC", print_=1)
'ABC?print_=1'
>>> url_for("ABC", host_="ab")
'ABC?host=ab'
>>> url("ABC", host_="ab")
'ABC?host=ab'
>>> url_for("ABC", host="example.com")
'http://example.comABC'
>>> url("ABC", host="example.com")
'http://example.comABC'
>>> url_for("ABC", host="example.com/")
'http://example.com/ABC'
>>> url("ABC", host="example.com/")
'http://example.com/ABC'
The last one is a bit surprising, that the 'host' argument needs a
trailing slash, but otherwise it seems to work fine and just needs to
be better documented.
> params (dict) - used to create the query string
That is an interesting idea. I'm not sure if I favor it or not. It
would mean I'd have to change an application I'm about to put into
production. But more importantly, the url_for tradition has been that
arguments not matching path variables are turned into query
parameters. If an expected variable is missing, that makes it obvious
what the problem is if you know what to look for. On the other hand,
I suppose an exception would make it even more obvious.
Part of the tentative plan for Routes 2 is to turn the extra variables
in route definitions into a dict, for the same reason as is suggested
here. I tried it and ended up being lukewarm to the idea. (Do I
really want every route to have 'map.connect("name", "/path",
{"controller": "foo", "action": "fooaction"}'?) On the other hand,
eliminating ambiguity is an important goal.
> Actually, I think I like the idea of making the query params into a
> single argument. It could be a string like a=1&b=2 or a dict.
No! Encouraging the user to do their own interpolation and escaping
would be a step back into the Dark Ages.
It's like the old rails select() helper which took an HTML snippet of
options rather than a list.
--
Mike Orr <[email protected]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
