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.