I'm still debugging now, but there seems to be an issue using the special $anything token inside app-specific routes_in. It appears that the incoming URL is being applied to each app-specific routes_in one at a time before it is applied against routes_app.
I'll try to include more details later, but I wanted to bring it to your attention now. -Mike On Aug 7, 12:36 pm, Jonathan Lundell <[email protected]> wrote: > 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 usingroutes? > > 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 > >>>applevelroutes. > >>> To understand how it works readroutes.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 aroutes.py in the top level folder of an application, > >> and it will be used *instead* of the baseroutes.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 > >> baseroutes.py: routes_app. routes_app is processed identically to > >> routes_in, but the output must be anappname (or nothing). routes_app is > >> processed at the beginning of a request. If it produces anappname, and > >> thatapphas anapp-specificroutes.py (that is, > >> applications/appname/routes.py), then thatroutes.py is used instead of the > >> baseroutes.py. > > >> 4. In an unrelated change, there are three other new elements inroutes.py: > > >> default_application = "init" > >> default_controller = "default" > >> default_function = "index" > > >> Note that default_application doesn't interact withapp-specfic routing, > >> since it's used after rewrite has taken place. default_controller and > >> default_function should normally be used only in anapp-specificroutes.py, > >> because, in the baseroutes.py, they will apply to all apps *without* > >> anapp-specificroutes.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 editroutes.example.py to generate a > >> newroutes.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 > >> "pythonroutes.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.
