Re: Routes user survey
On Dec 18, 2008, at 6:36 PM, Mike Orr wrote: file - controllers/semi_static.py controller - SemiStaticController method - faq Note that you can customize the controller name if desired by dropping a line into semi_static.py like so: __controller__ = 'MyClassController' Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Routes user survey
I can't seem to reply to the 'group', so i'm emailing the group address and 2 vocal people, hoping for the best. apologies if you get this 2x. something that i would LOVE to see in routes, is this: right now, routes maps like this: map.connect( 'faq_page', 'faq', controller='semi_static', action='faq') for: file - controllers/semi_static.py controller - SemiStaticController method - faq what i'd love is the ability to do something like this map.connect( 'faq_page', 'faq', controller='SemiStatic_Controller', action='faq') see, i hate the automagic mapping of semi_static to SemiStatic_Controller... i could get into a long argument about semantics, but i'll save us from boredom. i just think that if routes were to operate the same way, but also allow explicit controller naming ( identified by _Controller as the suffix ), it would totally rock. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
On Thu, Dec 18, 2008 at 4:44 PM, Jonathan Vanasco jonat...@findmeon.com wrote: I can't seem to reply to the 'group', so i'm emailing the group address and 2 vocal people, hoping for the best. apologies if you get this 2x. something that i would LOVE to see in routes, is this: right now, routes maps like this: map.connect( 'faq_page', 'faq', controller='semi_static', action='faq') for: file - controllers/semi_static.py controller - SemiStaticController method - faq what i'd love is the ability to do something like this map.connect( 'faq_page', 'faq', controller='SemiStatic_Controller', action='faq') see, i hate the automagic mapping of semi_static to SemiStatic_Controller... i could get into a long argument about semantics, but i'll save us from boredom. i just think that if routes were to operate the same way, but also allow explicit controller naming ( identified by _Controller as the suffix ), it would totally rock. Received. There's also a problem with not being able to specify the case of the controller, which can lead to monstrosities like MyxmlController or SqlalchemyController, which can be hard to read if you don't know the acronym ends and the adjacent word begins. I'm not sure what the most robust solution is, as you have to imply both the module name and class name, and it needs to work with modules in subpackages too. _Controller is too unobvious as a suffix. Maybe a symbol prefix like #. But in that case we might want to kill two birds with one stone and do #package.module:ClassController, using an entry point-like syntax for consistency. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
I've suspended my changes in light of Ben's new API, which is now
partly implemented.
I don't understand what exactly minimization means, and how
eliminating it changes Routes. Section 3.1 of the manual says:
1 m.connect(':controller/:action/:id', action='view', id=4)
2
3 # Will match all of the following
4 # /content/view/4
5 # /content/view
6 # /content
Does this mean that using the new map.dynamic(), only /content/view/4
will match?
What if I want the others to match too, specifically in the case of
/foo vs /foo/ vs /foo/index?
Does this clear up the problem of matching nonsense routes like
/archives/view- (missing ID), or will we still have to handle this
the same way?
Will 'action' and 'id' continue to be implicit arguments, or will they
have to be specified in every route?
What about on the generation side? I gather that minimization is what
makes url_for(name) choose the wrong route. But what is its other
impact? Routes 1 would leave out variables in the URL if the defaults
would match the same route?
On Nov 23, 2007 3:34 PM, Ben Bangert [EMAIL PROTECTED] wrote:
Regarding url_for(controller='account', action='home'), I have no
idea why this is regarded as an abomination nor do I have any plans
on dropping such a critical piece of functionality. In apps I've
worked on with 50+ controllers, with a dozen or more actions per
controller, it'd be an abomination to have to name every damn route. :)
Routes decouples the URLs from the actions. This allows you to rename
or move actions without affecting the URLs, or conversely to
reorganize the URLs without changing your controllers.
Named routes decouple the actions from the templates. Otherwise
you're hardwiring the names of controllers and actions in your
templates and wherever else url_for is called, and if you move actions
around you have to change your templates. That's a violation of MVC,
tying the templates to a specific controller implementation. Better
to give the routes meaningful logical names and arguments. For
instance, I want to show incident 23:
url_for(incident, incident_id=23, printable=1)
url_for(controller=main, action=incident, id=23, printable=1)
# Oops, I want to move it to controller incident action index.
url_for(/incident, incident_id=23, printable=1)
# Oops, I want to change the URL.
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
AW: Routes user survey
-Ursprüngliche Nachricht- Von: pylons-discuss@googlegroups.com [mailto:[EMAIL PROTECTED] Im Auftrag von Ben Bangert Gesendet: Samstag, 24. November 2007 00:35 An: pylons-discuss@googlegroups.com Betreff: Re: Routes user survey On Nov 23, 2007, at 1:37 AM, Mike Orr wrote: I've already started work on Routes again. Additions to Routes should be slip-streamed into 1.x releases, or if enough of them stack up in one release, that could be a 2.0 candidate. I could contribute changes required to enhance the subdomain support for recognizing other variables than HTTP_HOST. I think this feature is critical if you have a mixed environment where you try to induce Pylons apps through subdomain-links, as it is common in corporate Intranets. Currently my implementation look like: Instead of - mapper.sub_domain = True I do - mapper.sub_domain = (True, 'HTTP_X_FORWARDED_HOST) or - mapper.sub_domain = (False, None) to enable subdomain support and to indicate the related HOST-var. I could also do apply a different implementation if requested - I have all related LOCs identified where the related var needs to be used. Kind Regards, Andrew Smart --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: AW: Routes user survey
Andrew Smart wrote: -Ursprüngliche Nachricht- Von: pylons-discuss@googlegroups.com [mailto:[EMAIL PROTECTED] Im Auftrag von Ben Bangert Gesendet: Samstag, 24. November 2007 00:35 An: pylons-discuss@googlegroups.com Betreff: Re: Routes user survey On Nov 23, 2007, at 1:37 AM, Mike Orr wrote: I've already started work on Routes again. Additions to Routes should be slip-streamed into 1.x releases, or if enough of them stack up in one release, that could be a 2.0 candidate. I could contribute changes required to enhance the subdomain support for recognizing other variables than HTTP_HOST. If you use egg:PasteDeploy#prefix, it'll map HTTP_X_FORWARDED_HOST to HTTP_HOST. I think it's cleanest to fix up proxied environments to be accurate, rather than support all the individual options that proxies might use at the library level. For instance, it's not enough to just fix up routes to detect X-Forwarded-Host, you'd also have to fix up URL generation to use it, and there might be other parts as well (e.g., urlmap only looks at HTTP_HOST). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
redirect routes need some detailed design. a) There should be an easy way to define internal redirects. Important thing here is that the destination url should be defined using routes by itself. I am not sure about the syntax, but url_for need not be available at the moment (for example, if redirects need to be defined earlier than the destination routes) b) There should be some explicit way of selecting which kind of redirect is to be performed (permanent, temporary, ...). c) In case of internal redirects it may make sense to handle 'invisible redirect' (just picking the destination object using the redirected-to route without generating any redirect to the browser) as one of the methods. -- -- | Marcin Kasperski | People resist change, regardless of what | http://mekk.waw.pl | it is. (Michael Reed) || -- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Fwd: Routes user survey
On Nov 23, 2007 6:19 AM, Paweł Stradomski [EMAIL PROTECTED] wrote: Well, I think the current solution (function being passed by the framework to routes) is better, as it gives more flexibility. Throwin an exception would force just a single way of informing the framework about redirects - and is a bad idea, as this propagating exception might cause strange behaviour, like rolling back database sessions. Hmm. Well, the match function is called in only one place by the framework, so it would be easy to catch it close to the source. And without an exception it would have to have two very different return values: a match dict or a string destination. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
please don't get rid of url_for(controller='foo', action='bar') I use
that all the time, and although I know that url_for('named route') does
look more elegant, if you get rid of the former behavior, then we're
left having to name all of our controller/actions pairs. To me this
looks like just an extra step, and leaves me with haveing to remember
what edit_foobar really refers to, when controller='foo, action='edit'
is very explicit, I know exactly what it is revering to no guessing and
I don't have to look in an other file to make sure I'm pointing to the
right spot.
Jose
Mike Orr wrote:
A few of us have been kicking around ideas for improving Routes. I've
got an API proposal at
http://wiki.pylonshq.com/display/routes/Proposed+Changes
I'd like some feedback from those who use Routes heavily on whether
you use the less-common features like 'filter', 'function', '_static',
'url_for(controller=foo)'... whether the proposed changes would
totally screw up your application. They would require you to change
some of your routes and url_for's, but hopefully wth the effect of
making Routes simpler and more deterministic.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Fwd: Routes user survey
On Nov 23, 2007 7:34 AM, Paweł Stradomski [EMAIL PROTECTED] wrote: W liście Mike Orr z dnia piątek 23 listopada 2007: On Nov 23, 2007 6:19 AM, Paweł Stradomski [EMAIL PROTECTED] wrote: Well, I think the current solution (function being passed by the framework to routes) is better, as it gives more flexibility. Throwin an exception would force just a single way of informing the framework about redirects - and is a bad idea, as this propagating exception might cause strange behaviour, like rolling back database sessions. Hmm. Well, the match function is called in only one place by the framework, so it would be easy to catch it close to the source. And without an exception it would have to have two very different return values: a match dict or a string destination. But redirect_to might be called by the user. So redirect_to can stay the same. I would actually prefer that redirect_to would get replaced by raise Redirect, but it's too established in Pylons apps to change it now. However, there are a couple ways to make the matching side more to your liking. There are two special cases: status with location (redirect), and status without location (gone, forbidden, future statuses). This could be handled by two special keys in the match dict (_status and _location). If present, the framework should call a special controller to handle them. This would allow the user to customize the response if desired. Or routes could choose the controller and action itself, either via attributes (the way .sub_domains is handled now), or via ordinary controller/action arguments. The latter would avoid changes to Routes itself but would add boilerplate verbosity to the route definitions. m.connect(None, foo/foo, location=http://example.com/bar/bar.html;, controller=special, action=redirect, status=303) At least that would define a standard Pylons way to support redirects/statuses without forcing each user to reinvent it on their own. Perhaps this can be tucked into one of the existing standard controllers somewhere. (The Template controller doesn't do much, for instance.) -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
W liście Mike Orr z dnia piątek 23 listopada 2007: On Nov 23, 2007 5:46 AM, Paweł Stradomski [EMAIL PROTECTED] wrote: W liście Marcin Kasperski z dnia piątek 23 listopada 2007: redirect routes need some detailed design. If we had a separate redirect layer, where would it reside? As a separate function in routing.py that wraps make_map? How would you define the source routes, and wouldn't that be essentially making a second route map? If you add variables, it starts looking even more like a route map. And what if the user wants to group redirects next to their corresponding official route? If they're in separate functions, he can't. In fact I'm using routes inside cherrypy project (albeit with my own dispatcher, not the default one). Because of that I needed to look a bit into routes internals and I've found that routes redirect_to just generates the url and calls the framework's function for performing a redirect (which needs to be passed by the framework). So the call tree looks like: * user's code * routes redirect_to * url_for * framework's function for redirects That could be changed to: * user's code * framework's redirect_to * routes url_for * framework's function for redirects This would allow more flexibility on redirects - routes does not need to know how many redirect kinds are there. I'm afraid this is a case where purity hinders practicality. My application has several tiny actions that do nothing but redirect legacy URLs. The Routes map is the natural place for this, especially since it's about ROUTE-ing or matching URLs to destinations. Routes fulfills a function similar to mod_rewrite, which also handles both internal and external redirects, so it provides a precedent. I see your point - this would allow defining the redirect type in the route. So this might be feasible. One problem may be how to do the redirect in a framework-neutral way.. Routes may have to simply raise a Redirect exception with the destination, and let something else catch it and generate the Response. Well, I think the current solution (function being passed by the framework to routes) is better, as it gives more flexibility. Throwin an exception would force just a single way of informing the framework about redirects - and is a bad idea, as this propagating exception might cause strange behaviour, like rolling back database sessions. -- Paweł Stradomski --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
On Nov 23, 2007 5:46 AM, Paweł Stradomski [EMAIL PROTECTED] wrote: W liście Marcin Kasperski z dnia piątek 23 listopada 2007: redirect routes need some detailed design. I think that this does not belong to routes - but to pylons in general. In fact I believe that redirect function in routes is unnecessary - it should just take care of matching and generating urls, with no regard as to where the generated url is used. That would give a cleaner separation of concerns, and redirect function could just be defined in some layer using routes - and that function would accept parameters describing type of redirect (internal, moved permanently, moved temporarily, see other...) I'm afraid this is a case where purity hinders practicality. My application has several tiny actions that do nothing but redirect legacy URLs. The Routes map is the natural place for this, especially since it's about ROUTE-ing or matching URLs to destinations. Routes fulfills a function similar to mod_rewrite, which also handles both internal and external redirects, so it provides a precedent. If we had a separate redirect layer, where would it reside? As a separate function in routing.py that wraps make_map? How would you define the source routes, and wouldn't that be essentially making a second route map? If you add variables, it starts looking even more like a route map. And what if the user wants to group redirects next to their corresponding official route? If they're in separate functions, he can't. Here we have a separate method (not .connect) defining the redirect. That potentially allows all the code to be encapsulated into a separate module. Routes already has a redirect_to function, so it already has some notion about redirection. This is merely pushing it to its conclusion. One problem may be how to do the redirect in a framework-neutral way.. Routes may have to simply raise a Redirect exception with the destination, and let something else catch it and generate the Response. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
W liście Marcin Kasperski z dnia piątek 23 listopada 2007: redirect routes need some detailed design. a) There should be an easy way to define internal redirects. Important thing here is that the destination url should be defined using routes by itself. I am not sure about the syntax, but url_for need not be available at the moment (for example, if redirects need to be defined earlier than the destination routes) b) There should be some explicit way of selecting which kind of redirect is to be performed (permanent, temporary, ...). c) In case of internal redirects it may make sense to handle 'invisible redirect' (just picking the destination object using the redirected-to route without generating any redirect to the browser) as one of the methods. I think that this does not belong to routes - but to pylons in general. In fact I believe that redirect function in routes is unnecessary - it should just take care of matching and generating urls, with no regard as to where the generated url is used. That would give a cleaner separation of concerns, and redirect function could just be defined in some layer using routes - and that function would accept parameters describing type of redirect (internal, moved permanently, moved temporarily, see other...) -- Paweł Stradomski --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
Mike Orr wrote:
On Nov 23, 2007 5:46 AM, Paweł Stradomski [EMAIL PROTECTED] wrote:
W liście Marcin Kasperski z dnia piątek 23 listopada 2007:
redirect routes need some detailed design.
I think that this does not belong to routes - but to pylons in general.
In fact I believe that redirect function in routes is unnecessary - it should
just take care of matching and generating urls, with no regard as to where
the generated url is used. That would give a cleaner separation of concerns,
and redirect function could just be defined in some layer using routes - and
that function would accept parameters describing type of redirect (internal,
moved permanently, moved temporarily, see other...)
I'm afraid this is a case where purity hinders practicality. My
application has several tiny actions that do nothing but redirect
legacy URLs. The Routes map is the natural place for this, especially
since it's about ROUTE-ing or matching URLs to destinations. Routes
fulfills a function similar to mod_rewrite, which also handles both
internal and external redirects, so it provides a precedent.
I am guessing that something simple could be done right now, with a
generic controller that takes one parameter, the new (possibly relative)
URL to redirect to. Maybe like:
map.connect('/legacy/:id', redirect_to='/new/:id', controller='redirector')
Of course controller doesn't work right here. Is there a way to give
a controller that isn't in the application namespace? Anyway, given
that, if it also knows how to substitute :id for the id variable, one
redirecting controller can handle all redirects.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Routes user survey
On Nov 23, 2007 4:30 AM, Marcin Kasperski [EMAIL PROTECTED] wrote: c) In case of internal redirects it may make sense to handle 'invisible redirect' (just picking the destination object using the redirected-to route without generating any redirect to the browser) as one of the methods. How is this different from a regular route? -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
W liście Mike Orr z dnia piątek 23 listopada 2007: On Nov 23, 2007 6:19 AM, Paweł Stradomski [EMAIL PROTECTED] wrote: Well, I think the current solution (function being passed by the framework to routes) is better, as it gives more flexibility. Throwin an exception would force just a single way of informing the framework about redirects - and is a bad idea, as this propagating exception might cause strange behaviour, like rolling back database sessions. Hmm. Well, the match function is called in only one place by the framework, so it would be easy to catch it close to the source. And without an exception it would have to have two very different return values: a match dict or a string destination. But redirect_to might be called by the user. -- Paweł Stradomski --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes user survey
On Nov 23, 2007, at 1:37 AM, Mike Orr wrote:
A few of us have been kicking around ideas for improving Routes. I've
got an API proposal at
http://wiki.pylonshq.com/display/routes/Proposed+Changes
I'd like some feedback from those who use Routes heavily on whether
you use the less-common features like 'filter', 'function', '_static',
'url_for(controller=foo)'... whether the proposed changes would
totally screw up your application. They would require you to change
some of your routes and url_for's, but hopefully wth the effect of
making Routes simpler and more deterministic.
I've already started work on Routes again. Additions to Routes should
be slip-streamed into 1.x releases, or if enough of them stack up in
one release, that could be a 2.0 candidate.
People need existing minimized routes to be *recognized*, this is
critical to avoid losing ppl that had an old URL.
Generally, to simplify the API and make things more obvious,
additions are going in as new mapper option which attach different
type of Routes. There will be:
1) RedirectRoute, which handles generating redirects (requires use of
Routes middleware, which is used by Pylons by default)
2) DynamicRoute, the new 'normal' route
3) StaticRoute, for generating URL's to common locations. These will
actually support variable substitution unlike the current static
routes which can only add on query args. I might also consider
calling it 'GenerateRoute' or something to make it clearer its used
for URL generation only.
The current 'connect' method will connect a LegacyRoute to the mapper
which also uses route memory for that request if matched. This way a
smooth transition to using new Routes features can be accomplished.
The DynamicRoute will also have a 'legacy_match=True' and
'legacy_redirect=True' option. The latter of which will generate a
RedirectRoute for the old minimized URL's to the new non-minimized
URL. The first will merely allow matching of both. All generation of
URL's will never be minimized.
To prevent the rather odd usage of _method args constantly for the
route, defaults will be a keyword option itself. This way its obvious
what is what.
For example:
map.dynamic(':controller/:action/:id', defaults=dict(action='index',
id=None), conditions=dict(...))
and:
map.static('http://amazon.com/service/:key/:method')
map.named('account/:action/:var', name='account', defaults=dict
(action='home'))
map.redirect('legacy/url/:action/:controller', ':controller/:action/
legacy')
Variables can be specified in the redirect URL, and used easily in
the new URL to construct. Note that when you provide a DynamicRoute
style variable path in the new URL, it will use that with url_for and
the args it matched in the first one, for the second.
One of the goals with this scheme, is that you can see at a quick
glance what kind of routes are present in your app, what the defaults
are, and easily hook up a URL matching *and* generating scheme that
makes sense for your app. The route path no longer changes location,
its *always* the first argument, and there's a bit more consistency
in where options are.
Regarding url_for(controller='account', action='home'), I have no
idea why this is regarded as an abomination nor do I have any plans
on dropping such a critical piece of functionality. In apps I've
worked on with 50+ controllers, with a dozen or more actions per
controller, it'd be an abomination to have to name every damn route. :)
My main goals for Routes 2.0:
A) Explicitness
B) Obvious at a glance
C) Predictable behavior with generation and matching
D) Removing and/or deprecating old minimization behavior and 'Route
Memory' behavior.
I believe the changes I'm currently adding should accomplish that for
the most part.
Cheers,
Ben
smime.p7s
Description: S/MIME cryptographic signature
