> -----Ursprüngliche Nachricht-----
> Von: [email protected]
> [mailto:[EMAIL PROTECTED] Im Auftrag von Mike Orr
> Gesendet: Mittwoch, 16. Januar 2008 20:12
> An: [email protected]
> Betreff: Re: Routes 2 spec
>
> Templates need a single route-generator object. Traditionally
> this has been a separate function 'url_for'. There's no
> reason it can't be the same object as the route map, though
> we can't call it 'm' because the trend has been away from
> one-letter globals. It also needs to be something other than
> 'url' and 'map' to avoid conflicting with common user
> variables or builtins, and distinct for grepping. I can't
> think of a better name than 'url_for'.
If there is the intention do differentiate the old and the new
approach (route 1 vs route 2) an alternative name could be
"geturl" - but thats just an idea...
>
> But 'url' for as an attribute can be shortened to 'url' or
> '.__call__'. The latter is closer to our original plan,
> which would result in:
>
> url_for['google']()
> url_for['google'](q='My Query")
>
I don't think that you need the () calling if no parameters
must be provided. url_for could do that implicitly - in my
understanding url_for is not a synonym for the mapper class.
I'm currently not so deep in the source, if I'm wrong just
forget my idea.
But: without the implicit calling (or any other simple
variant) we'll get lots of complaints and questions like
"I used url_for["google"] and no url gets created, I get a
error message XYZ in my templates" because the people forget
to add the ()...
> On the construction side, I guess we'd better stick with the
> name as the first argument:
>
> m.connect("name", "path", **variables)
>
> That:
> - avoids exposing the Route class, which gives us greater
> freedom in the implementation.
> - follows a Python tradition of using a factory function to
> instantiate an unexposed class and put it in a map.
> - Allows longer routes to fit on one line of code, especially
> if the user assigns "C = m.connect".
Thats fine.
>
> > I would be even more happier if routes 2 would consistently allow
> > proper subdomain handling... ;-))
>
> Ben has some ideas about this which he hasn't told me, so I
> don't know what he's cooking up. What are the problems with
> subdomains?
I had some trouble with the HTTP var which has been used to
identify the subdomain. In my configuration the subdomain must
be retrieved from HTTP_X_FORWARDED_HOST and not from HTTP_HOST.
Ian wrote something about egg:PasteDeploy#prefix which I haven't
investigated due to time restrictions on my side, but I'm not
sure if this would help in the routes area. To make it short:
routes just looks at HTTP_HOST, but in a Apache mod_proxy
environment the relevant subdomain is not found there but in
HTTP_X_FORWARDED_HOST.
Andrew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" 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-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
