On Aug 7, 2010, at 9:32 AM, David Marko wrote: > Hello, > have you tested performance impact on application. Do you assume some > noticeable slowdown when using routes?
I have not measured it, but I'd expect the effect to be trivial, perhaps unmeasurable in that it'd be in the noise. In particular, the routing files are read and the regexes compiled only once, when web2py starts up, so the per-request overhead is quite low. > > david > > On 7 srp, 18:26, Jonathan Lundell <[email protected]> wrote: >> On Aug 7, 2010, at 9:03 AM, mdipierro wrote: >> >>> Thanks to Jonathan Lundell we have an experimental version in trunk of >>> app level routes. >>> To understand how it works read routes.example.py and comments in the >>> file gluon/rewrite.py >> >>> If you test it please report your findings here. >> >> *Very* experimental, mostly not tested. >> >> I'll describe some of the changes here. >> >> 1. If you don't explicitly invoke any of the new features, routing should >> behave identically to before. If you see any different, please let us know >> asap. >> >> 2. You can now have a routes.py in the top level folder of an application, >> and it will be used *instead* of the base routes.py. However, it's not >> enough to simply have the file there; you must inform the routing logic >> about it. >> >> 3. The way you inform the routing logic is with a new element in the base >> routes.py: routes_app. routes_app is processed identically to routes_in, but >> the output must be an app name (or nothing). routes_app is processed at the >> beginning of a request. If it produces an app name, and that app has an >> app-specific routes.py (that is, applications/appname/routes.py), then that >> routes.py is used instead of the base routes.py. >> >> 4. In an unrelated change, there are three other new elements in routes.py: >> >> default_application = "init" >> default_controller = "default" >> default_function = "index" >> >> Note that default_application doesn't interact with app-specfic routing, >> since it's used after rewrite has taken place. default_controller and >> default_function should normally be used only in an app-specific routes.py, >> because, in the base routes.py, they will apply to all apps *without* an >> app-specific routes.py. That would probably lead to confusion when running >> admin or examples; at the very least their defaults would break. >> >> 5. As usual, I suggest that when you edit routes.example.py to generate a >> new routes.py, you also edit the doctest at the end, and use it to verify >> that you're getting what you expect. To run the doctest, just do "python >> routes.py". >> >> Note also that I have a more far-reaching change in mind, but don't have it >> worked out yet. The new version will move away from regexes (though the old >> logic will remain in place for compatibility). It's supposed to be more >> flexible and much easier to use, and also handle URL encoding & decoding >> better. But this change should help in the meantime.
