Here's what I want to be able to do with Routes. I do want to be able
to take advantage of the following cases of minimization, but I want
to be able to explicitly call controller/action/id when the defaults
i've set up are not enough. I'm curious how my scenario compares to
the above discussion. If I was another year deep in Pylons or web-dev
in general, I'm sure an answer to that question would be more clear to
me; instead, i'm asking this in order to learn more, if anyone is
willing to comment.
1. I want to be able to configure "index" as the default action when I
call url_for and supply a controller, but no action or id. Also,
since I know it's the default action in this case, the word "index"
does not need to appear in the URL. So url_for(controller="SomeClass")
should result in the URL "/SomeClass", which should link to controller
"SomeClass", action "index".
2. I want to be able to configure "show" as the default action when a
controller AND an id are given, but no action. And since I know it's
the default action in this case, the action need not show as a field
in the visible URL. So url_for(controller="SomeClass", id="16384")
should result in the URL "/SomeClass/16384", which should link to
controller "SomeClass", action "show", id "16384".
3. When other actions are needed (i.e. create, update, delete, etc.)
I'll supply controller, action, and id all to url_for and accept the
fact that all three fields need to shown in the URL.
I have almost, or sometimes (briefly) found the above combination
possible with the current Routes, but it seems fragile -- it takes a
lot of guesswork and blundering to get the exact order of routes in my
routing.py correct in order for one controller's defaults to not steal
the intent of some other controller. And adding another controller or
another type of action triggers a need to reconsider several of my
existing routes and where exactly to put the new information in order
to avoid disturbing the "ecosystem" of the existing set.
As a result of that seemingly fragile state of affairs, I have given
up on the minimization/defaults techniques that I had really hoped to
employ. Instead I've resorted to spelling out the controller and
action for every request. Of course that works fine, but the URLs of
course show information that I consider redundant or superfluous (such
as when the URL mentions a controller but no id, and therefore should
not have to explicitly mention the action "index" since index is the
only consistent action when no id is present).
It may be that I'm just not comprehending the relatively terse style
in the documentation. If that's the case then I just need to work
harder at it. But in the meantime I wanted to put this use case out
there -- it doesn't strike me as being unusual.
On Mar 8, 12:00 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 8, 2008 at 10:05 AM, Jose Galvez <[EMAIL PROTECTED]> wrote:
>
> > Mike Orr wrote:
>
> > On Fri, Mar 7, 2008 at 12:51 PM, Poli García <[EMAIL PROTECTED]> wrote:
>
> > Hi !
> > I'm having an issue with URL parameters. I have these routes mapped on
> > my routing.py:
>
> > map.connect('/a_url_path/:param1/:param2', controller='some_controller',
>
> > action='an_action')
>
> > map.connect('/another_url_path/', controller='some_controller',
>
> > action='another_action')
>
> > and some_controller.an_action defined as:
>
> > def an_action(self, param1, param2):
> > # Some work with param1 and param2
> > return render('/some_template.mako')
>
> > On some_template.mako I have an anchor defined as:
>
> > ${h.link_to('A Link', h.url_for(controller='some_controller',
>
> > action='another_action'))}
>
> > The problem occurs when I navigate to /a_url_path/a_value/another_value.
> > The
> > link on the page is rendered as
> > /another_url_path?param1=a_value¶m2=another_value. It's like all URL
> > parameters are propagated to the links. This doesn't happen always.. and I
> > cannot figure out the occurrence pattern. If I name the second route and
> > create the link using the name of the route, the parameters are not
> > propagated.
>
> > Can someone tell me how to avoid this?
>
> > The Routes algorithms are too complex and occasionally lead to
> > situations like this. Your best bet is to use named routes, but even
> > that can fail sometimes. The problem is that 'another_url_path' has
> > no variables in it, so url_for is choosing it when it shouldn't. When
> > I've encountered this -- mainly with links to static files -- I've
> > just tried different things till it works, or used hardcoded URLs if
> > it just won't.
>
> > Routes 2 will simplify the algorithms greatly, and probably require
> > all routes and url_for calls to use route names, so that should
> > eliminate this problem in a couple months. You will have to change
> > your routing rules so be prepared. (Although you'll be able to stick
> > with Routes 1 if you're happy with your current routing rules.)
>
> > I hope not, I would hate to have to name all my routes, especially when
> > controller=foo, action=bar is much more informative then a route named
> > fooBar
>
> That only works due to variable matching ; i.e., it chooses the route
> with the highest number of common variables between the route
> definitions and the values supplied. This is an imprecise algorithm
> that sometimes chooses the wrong route, which is why url_for sometimes
> spits out a URL that's not even close to correct. Variable matching
> and minimization make Routes a pain to write unit tests for and debug.
> So the goal of Routes 2 is to make it much more straightforward and
> deterministic.
>
> There's another problem with url_for(controller="foo", action="bar")
> in that it makes the URLs and controller/action names dependent on
> each other, which defeats the purpose of Routes. Other frameworks
> have a built-in dispatcher that maps a URL to an action with a certain
> name. Routes exists to let you restructure your URLs independently
> from your controllers/actions and vice-versa, and then change the
> connections between the two. With named routes this works seamlessly
> and all the url_for calls remain valid. But url_for(controller="foo",
> action="bar") assumes there's a route ":controller/:action" and a
> class 'Controller' with method 'action'. If you change either the URL
> path or the controller name or action name, the url_for call breaks
> and you have to go changing url_for calls all over your application.
>
> You don't name routes "fooBar" to match the controller/action; you
> give them some kind of semantic name. If it's a FAQ section, name it
> "faq" -- regardless of what the URL or action name is. If it's
> article 15 in the platypus section, name it "platypus_article" or
> "animal_article". Something that's globally unique and comprehensible
> on its own.
>
> Having said that, url_for(controller="foo", action="bar") may be
> supported with a default route. We're still going back and forth on
> that. But the idea is you would define a special route
> (":controller/:action") in this context) which would be tried last
> during matching; i.e., if all the named routes fail. Conversely, a
> separate url_for method would choose the default route. So instead of
> url_for.name(**variables), you would do url_for(**variables), and it
> would consider only the default route.
>
> To truly do what you want -- "Return the URL for controller 'foo'
> action 'bar', no matter which route it is -- would require a separate
> route index keyed by (controller, action). That's possible but it
> would require some infrastructure we hadn't intended. I'll think
> about it. One issue is it ties Routes to Pylons conventions
> ('controller' and 'action'), while we were trying to make it
> framework-neutral. Maybe Routes needs a neutral base class and Pylons
> subclass.
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
