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.
