On Jan 5, 9:56 am, Ben Bangert <[email protected]> wrote:
> On Jan 4, 2009, at 9:06 PM, Tycon 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...
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. I don't
think url_for('/wherever', host='pants.com', params=dict(a=1, b=2)) is
too annoying. It's only a few more characters more than the current
API but removes all ambiguity.
Too maintain backward compatibility, if ``params`` is present as a kw
arg in the url_for call, url_for would send only those query params,
consuming the remaining kw args itself. Otherwise, if ``params`` isn't
present, the old behaviour would apply.
Note: This is off the top of my head. I haven't reviewed the source/
API extensively too see how feasible this idea really is or to make
sure I covered all the bases.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
