Re: Improving URL Dispatch
I was not among those who reported Item #2, but now that you mention it, that one has been gnawing on me for months. I had not chanced to articulate it well enough in my mind to ever bring it up as a subject for discussion, but I'll +1 it here and give my 2 cents that it's a definite annoyance. In the spirit of making everything very explicit, I have been OK with working with the current behavior thus far. But it would also be nice to save some typing. I believe I have heard a few visitors/dabblers say things like dear god, I have to spell out every route and give each one a name too, even when two are nearly the same thing but one is a special case of the other?. Well, we've been down the road of route minimization before a la Pylons/Routes, and I guess you would have to have been there and seen the difficulties/ambiguities that come with that approach. So it's not like there's really a call to bring back minimization. But anything you can do to reduce the verbosity of the add_handler and route naming pattern will surely be appreciated. - ejo On Jul 18, 8:44 pm, Michael Merickel mmeri...@gmail.com wrote: Hey people, I've been looking into ways to resolve some of the most common complaints with URL Dispatch. The few that I have seen more than once in the past are: 1) I have a lot of placeholders in this URL, generating it is a pain and I'd like to supply some defaults so that when using route_url I don't have to send it *everything*. This is already possible by supplying a pregenerator to your route, however I've created a pre-baked DefaultsPregenerator for this purpose and thrown it into the add_route API to service: config.add_route('foo', '/bar/{baz}', defaults={'baz': 5}). Is this common enough that it warrants the extra API in add_route? 2) I'm using pyramid_handlers or pyramid routes/views and it's a pain to have to specify different route names for logically similar patterns. For example, using handlers: config.add_handler('users_index', '/users', handler=UserHandler, action='index') config.add_handler('users', '/users/{action}', handler=UserHandler) When generating URLs for this handler, you need to remember that if you want the 'index' action, it's users_index, and for everything else it's users. I've implemented a RouteGroup concept here:https://github.com/Pylons/pyramid/blob/feature.dispatch-defaults/pyra... The idea is that you can group patterns, and (similar to the Pylons-style Routes package) it will attempt to determine which pattern you wanted to use for a particular set of placeholders. This particular branch keeps it pretty sane and does the matching by only looking at the set of supplied parameters to route_url and finding the matching route with the largest number of placeholders. Integrating something like this into Pyramid depends on what use-cases we are trying to solve. 3) Dispatch isn't as extensible as traversal. This will always be the case, but we've created a branch that enhances config.include('some_package', route_prefix='/users') to enhance the relativity of routes by mounting a package at a particular prefix. I'm basically searching for opinions on the topics to judge whether they are useful to have in Pyramid. Obviously a major goal of these features is that there is no performance impact if you choose to not use them. The current dispatch is raw, but it works and it's pretty general, so I was looking at ways to add some convenience APIs to help people out with common dispatch use-cases. Thanks for your ideas, and hopefully this isn't just bike shedding. :-) -- Michael -- 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 pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Improving URL Dispatch
Sorry, with you'd have to have been there I was referring to people who are just checking out Pyramid recently, arriving from some different background, not addressing that to you. On Jul 20, 12:41 am, Eric Ongerth ericonge...@gmail.com wrote: I was not among those who reported Item #2, but now that you mention it, that one has been gnawing on me for months. I had not chanced to articulate it well enough in my mind to ever bring it up as a subject for discussion, but I'll +1 it here and give my 2 cents that it's a definite annoyance. In the spirit of making everything very explicit, I have been OK with working with the current behavior thus far. But it would also be nice to save some typing. I believe I have heard a few visitors/dabblers say things like dear god, I have to spell out every route and give each one a name too, even when two are nearly the same thing but one is a special case of the other?. Well, we've been down the road of route minimization before a la Pylons/Routes, and I guess you would have to have been there and seen the difficulties/ambiguities that come with that approach. So it's not like there's really a call to bring back minimization. But anything you can do to reduce the verbosity of the add_handler and route naming pattern will surely be appreciated. - ejo On Jul 18, 8:44 pm, Michael Merickel mmeri...@gmail.com wrote: Hey people, I've been looking into ways to resolve some of the most common complaints with URL Dispatch. The few that I have seen more than once in the past are: 1) I have a lot of placeholders in this URL, generating it is a pain and I'd like to supply some defaults so that when using route_url I don't have to send it *everything*. This is already possible by supplying a pregenerator to your route, however I've created a pre-baked DefaultsPregenerator for this purpose and thrown it into the add_route API to service: config.add_route('foo', '/bar/{baz}', defaults={'baz': 5}). Is this common enough that it warrants the extra API in add_route? 2) I'm using pyramid_handlers or pyramid routes/views and it's a pain to have to specify different route names for logically similar patterns. For example, using handlers: config.add_handler('users_index', '/users', handler=UserHandler, action='index') config.add_handler('users', '/users/{action}', handler=UserHandler) When generating URLs for this handler, you need to remember that if you want the 'index' action, it's users_index, and for everything else it's users. I've implemented a RouteGroup concept here:https://github.com/Pylons/pyramid/blob/feature.dispatch-defaults/pyra... The idea is that you can group patterns, and (similar to the Pylons-style Routes package) it will attempt to determine which pattern you wanted to use for a particular set of placeholders. This particular branch keeps it pretty sane and does the matching by only looking at the set of supplied parameters to route_url and finding the matching route with the largest number of placeholders. Integrating something like this into Pyramid depends on what use-cases we are trying to solve. 3) Dispatch isn't as extensible as traversal. This will always be the case, but we've created a branch that enhances config.include('some_package', route_prefix='/users') to enhance the relativity of routes by mounting a package at a particular prefix. I'm basically searching for opinions on the topics to judge whether they are useful to have in Pyramid. Obviously a major goal of these features is that there is no performance impact if you choose to not use them. The current dispatch is raw, but it works and it's pretty general, so I was looking at ways to add some convenience APIs to help people out with common dispatch use-cases. Thanks for your ideas, and hopefully this isn't just bike shedding. :-) -- Michael -- 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 pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Improving URL Dispatch
Hey people, I've been looking into ways to resolve some of the most common complaints with URL Dispatch. The few that I have seen more than once in the past are: 1) I have a lot of placeholders in this URL, generating it is a pain and I'd like to supply some defaults so that when using route_url I don't have to send it *everything*. This is already possible by supplying a pregenerator to your route, however I've created a pre-baked DefaultsPregenerator for this purpose and thrown it into the add_route API to service: config.add_route('foo', '/bar/{baz}', defaults={'baz': 5}). Is this common enough that it warrants the extra API in add_route? 2) I'm using pyramid_handlers or pyramid routes/views and it's a pain to have to specify different route names for logically similar patterns. For example, using handlers: config.add_handler('users_index', '/users', handler=UserHandler, action='index') config.add_handler('users', '/users/{action}', handler=UserHandler) When generating URLs for this handler, you need to remember that if you want the 'index' action, it's users_index, and for everything else it's users. I've implemented a RouteGroup concept here: https://github.com/Pylons/pyramid/blob/feature.dispatch-defaults/pyramid/urldispatch.py#L47 The idea is that you can group patterns, and (similar to the Pylons-style Routes package) it will attempt to determine which pattern you wanted to use for a particular set of placeholders. This particular branch keeps it pretty sane and does the matching by only looking at the set of supplied parameters to route_url and finding the matching route with the largest number of placeholders. Integrating something like this into Pyramid depends on what use-cases we are trying to solve. 3) Dispatch isn't as extensible as traversal. This will always be the case, but we've created a branch that enhances config.include('some_package', route_prefix='/users') to enhance the relativity of routes by mounting a package at a particular prefix. I'm basically searching for opinions on the topics to judge whether they are useful to have in Pyramid. Obviously a major goal of these features is that there is no performance impact if you choose to not use them. The current dispatch is raw, but it works and it's pretty general, so I was looking at ways to add some convenience APIs to help people out with common dispatch use-cases. Thanks for your ideas, and hopefully this isn't just bike shedding. :-) -- Michael -- 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 pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.