This fixed the problems I was having. I'll let you know if I run into anything else.
Great work by the way...app-specific routes are a huge plus for web2py. -Mike On Aug 31, 1:31 pm, Jonathan Lundell <[email protected]> wrote: > On Aug 31, 2010, at 10:16 AM, Jonathan Lundell wrote: > > > > > 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 fromapp-specificroutes_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. > > Here's an updated rewrite.py. Easier to follow, too, I think. > > http://web.me.com/jlundell/filechute/rewrite.zip > > Massimo, you should probably hold up 1.84 until this gets resolved. > > > > > > >> -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.
