On Aug 31, 2010, at 9:31 AM, mwolfe02 wrote: > > 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.
Thanks. I'll wait to hear from you. It should look at the global routes_app first (because it doesn't know which app-specific routes to use), and if that resolves to an app that has its own routes file, then use that for routes_in. > > -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.
