On Aug 31, 2010, at 10:01 AM, mwolfe02 wrote: > > 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...
I think I may see the problem. If I'm right, when we initialize a new set of params from the default set, we need to do a deeper copy than we're doing now. Can I send you a replacement rewrite.py to try out? It'd be from the trunk, which ought to be equivalent, for our purposes, to the current nightly and close enough to the last stable release. > > -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.
