2010/11/19 Ben Bangert <b...@groovie.org>:
> After some discussion, it seemed reasonable to also have Pyramid use the new
> Routes style syntax for grouping markers (the dynamic bit) in a pattern:
> '/articles/{action}/{id}'
Great, I prefer this form!
> As this allows for multiple markers in the same path segment, and provides
> leeway for additional functionality like including a regular expression:
> '/articles/{action}/{id:\d+}'
>
> I've updated pyramid to now honor this format, and the docs reflect it. As
> with Pylons 1.0, the old ':marker' syntax still works but the official
> documented style will be with braces.
Great! It will be less likely that I will work on projects with the
old syntax. I am not quite sure why this wasn't here by default. I saw
a long thread about Routes but I didn't follow it all the way. I
should take a look at it again.
> This helps get pyramid a lot closer to Routes parity which I've considered a
> major requirement before larger Pylons 1.0 applications may be able to switch
> over. Especially for those using the sub_domains feature of Routes which is
> unavailable without a lot of custom stuff in pyramid at the moment.
>
> Next on my list is pyramid_routehelper, which will try to complete the
> routing functionality and even top what Routes provides. An idea I've been
> toying with since seeing it in werkzeug's routes, is the concept of
> converters... as I'm really not a fan of int(..) all over to convert things
> from the URL... over.. and... over... again.
I currently work on a project right now which is a real casting pain,
as you say, "int(...)" all over the place. I wish I could have my IDs
passed as an int to my controller's action. I wanted to come up with
that sooner or later.
> However, in werkzeug, the function call to customize the conversion occurs
> inside the pattern string itself, which I'm really not a fan of, also, you
> still have to keep specifying it over and over again for each route. I've
> been thinking of implementing it more like this though:
> 1) You declare converters, and the converter name they should use
> 2) When writing routes, instead of supplying a regex, if the name is a
> converter you've declared, that is used
>
> So, assuming we have a converter called converter.Integer, that supplies a
> regular expression of \d+, and you've named it 'int', you could use it like
> this:
> '/articles/{id:int}'
I like that, it's very elegant IMO.
> And it will use \d+ as the regular expression, and do the int() type
> conversion for you. However, you could also register a marker name itself to
> automatically have a converter applied. For example, maybe in your
> application, {id} should *always* be \d+ and converted to an int(). Why type
> that over and over again?
> with routehelper(config, global_converters=dict(id=converter.Integer())) as r:
> r.add_route('articles', '/articles/{id}'....)
I don't feel I'd use that very much. It's like having globals set in
your app, you don't really know what's happening (even though the
context manager helps in readability). I'd rather have explicitly
{id:int} so I am sure it is casted to whatever the "int" named
converter returns. You know what each route does just by looking at
it.
> In my experience, lots of people end up repeating themselves a ton as their
> marker names frequently require the same regular expression and type
> coercion. It'd be nice to have that all taken care of without clouding up the
> view code.
>
> Any thoughts on converters or being able to register default regular
> expressions for route markers?
As I said, I like the named converted idea and syntax. But I am not a
fan of the context manager style (although, having it doesn't hurt if
you don't want it).
--
Alex | twitter.com/alexconrad
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@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.
