We can either make a clean, explicit Routes 2 where every feature is
justified by use cases, or reintroduce cruft from Routes 1 in a false
attempt to make it more compatible. False because it won't be fully
compatible, bad because it retains ambiguities we're trying to get rid
of, and useless because Routes 1 will still exist and those who want
the old behavior will want the real enchilada.
'm.my_name' is unexpected and collision-prone, as I said. I'm not
wedded to it. Maybe m.connect("name", ...) is better because it's
standard Python syntax. But I do like url_for.my_name(); it promises
to make templates and controllers more readable by getting the name
away from a sea of quoted arguments. But on the other hand it would
be nice to have url_for and .connect be parallel, and url_for("name")
is OK.
On Jan 15, 2008 5:34 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> On Jan 15, 2008, at 7:26 AM, Max Ischenko wrote:
>
> > My main question is: will Route 2 remain compatible (API) with
> > Routes 1?
>
> Almost completely, yes. It will be generally frowned upon to be using
> ur_for like, url_for(controller=..., action=...), but that will still
> work and go to the Route default.
Now you're saying different things to different people. You told me
last night that unnamed access can be dropped. Well, if you want to
support least-unmatched-variables lookup, you can write the code and
tests for it.
I wouldn't say "almost completely" compatible. Differences:
- Mapper => RouteMap
- Add '_match' flag, delete '_static', change 'requirements' to
'_requirements'. Change conditions
syntax.
- Route memory requires url_for.current rather than url_for.
> > 3. "Unnamed routes will no longer be allowed". I remember Ben saying
> > this will never happen.
>
> You'll be able to do a single 'default' route. That can be used by
> unnamed routes, since you'll know which route its going to use at least.
The minimum spec calls for eliminating the default route. I thought
you said that was OK too. There's no difference between a default
route and a last route during matching. The only difference in the
API is you could define the default route before other routes.
Without minimization, a default route is fairly useless unless people
access it with exactly the right number of variables.
What I'm concerned about is, the spec was intentionally written to
have a minimum required API and optional extensions, so we could
decide which extra features to support. Saying we're going to have
default routes and nameless generation is equivalent to saying we will
include these optional features. That's either a decision (in which
case it should be definitively noted in the spec itself) or an offhand
remark (in which case it makes a promise that may be false). The plan
as I understood it was to have a straightforward and well-tested
minimum implementation, and then add optional features maybe.
Especially REST resources and conditions, which require further
thinking.
What are the reasons to support 'url_for(controller="foo",
action="bar")'? Besides to avoid rewriting old routes? Is there some
independent advantage to it? While it's sometimes a hassle to name a
lot of little unimportant routes, and 'm.connect("main", "main",
controller="main")' gets a bit redundant, the cleanliness of always
using named routes is a big advantage.
On Jan 15, 2008 5:53 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> Max Ischenko wrote:
> > Again, I don't see how url_for().foobar is better then
> > url_for("foobar").
>
> What if you want a relative URL to foobar?
> url_for.foobar(**extra_args) definitely seems a little nicer to me.
I think you're both talking about different things, and Max is
misunderstanding the spec. The syntax is
url_for.foobar()
not
url_for().foobar
You all see the Python implications of the difference.
As for relative URLs, I'm ambivalent about them. If you've properly
defined and named all your routes, you won't need relative URLs.
Generating URLs that aren't in the route map, or have a different
official name than how you're generating them, means you're putting
original URL information in your templates, which will have to be
hunted down and changed if your URL hierarchy changes. That's exactly
what Routes exists to prevent. Routes is about putting your entire
URL hierarchy in one place, and making it independent of the rest of
the application.
Changing the query params on the current URL isn't quite the same
thing, because you shouldn't have to recite the official route of the
current URL to make a link back to itself.
--
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 [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
-~----------~----~----~----~------~----~------~--~---
