More clues... When web2py loads, rewrite.params.routes_in gets set as follows:
- items from base routes_in are appended first - then items from app-specific routes_in are appended in alphabetical order by application This seems to be causing my problems. More info to follow... -Mike On Aug 31, 12:31 pm, mwolfe02 <[email protected]> wrote: > I'm still debugging now, but there seems to be an issue using the > special $anything token insideapp-specificroutes_in. It appears > that the incoming URL is being applied to eachapp-specificroutes_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.
