On Fri, Nov 19, 2010 at 1:38 PM, Ben Bangert <b...@groovie.org> wrote:
> 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.
A converter sounds like a validator, which suggests FormEncode. Does
Pyramid have any built-in infrastructure for validators? Requiring
FormEncode would anger some people, but using different validator
libraries in different parts of the application would also be bad.
It seems like Pyramid should have a generic "validator" feature akin
to its "component" feature. Because validation/conversion comes up in
forms, INI files, and now URL parsing.
> 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}'
It does get tiring to put "\d+" all over the place, and can be less
readable with less obvious regexes. I define a NUMERIC regex in my
apps, for use with the Routes 'requirements' dict.
The main goal is to keep configuration together rather than scattered.
Right now there's three places for dispatch/view configuration: in the
config.add_handler() call, and in the view method and its decorators.
Routes has a problem in that if you restrict a route to POST, it
doesn't really restrict the action, and you can't see in the action
code that the route is POST-only (or that the restriction is not
actually there, oops!). Conversely, if you restrict the action to
POST-only and a GET request is routed to it anyway, the user will get
an error rather than Routes being able to look for a more appropriate
action.
Likewise, it's the view that needs the variable to be a certain type,
but the type is specified in the routing, so those two things are
separate, and the same problem can occur when the view thinks the
route is doing something but the route is actually doing something
different.
As for contexts, I don't really understand them yet, nor factories or
root contexts or content managers, so I'm not sure how they are
factors.
> like how Routes has a submapper:
http://routes.groovie.org/setting_up.html#submappers
Submappers are a new feature in Pylons 1.0, and they make a lot of
configuration easier, but most people aren't familiar with them enough
yet to realize their potential. It would be great if Pyramid has a
similar feature. It could also help with the resource route issue:
some kind of helper for that combined with a submapper.
--
Mike Orr <sluggos...@gmail.com>
--
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.
