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.
