On Jan 15, 2008 11:45 PM, Andrew Smart <[EMAIL PROTECTED]> wrote:
> I just want to add some sugar to the discussion:
>
> Instead of
> m.connect("foobar", vars) it was proposed: m.foobar(vars...)
>
> One option could be:
> m.routes.foobar(vars...)
> => adding a central var under which all named routes are accessible as
> attributes
>
> Alternativly:
> m["foobar"] = routedef(vars...)
> => which would require a additional class which is used for
> instantiation of the
> routing definition (holding the vars)
> => access to the named routes in a way which shows that the mapper is a
> kind of
> data storage for routes
>
> This approach would also allow to make something like:
> myroute = m["google"]
> myroute.url_for(vars...)
>
> or shorter:
> m["google"].url_for(vars...)
Now we're talking. This may be the best compromise. It avoids
conflicts, allows calculated names, and keeps the name separate from
the variables. I do like url_for.home(), but I certainly don't want
to make people use getattr for a calculated name.
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'.
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")
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".
> 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?
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
