default_function does not seem to be recognized properly in app- specific routes.py. I'm thinking default_controller may have a similar problem, but I'm not really redefining it.
My base routes.py has default_application set to 'my_app' (and nothing set for default_controller or default_function). In the routes.py file for my 'my_app' I have the following set: default_controller = 'default' # ordinarily set in app-specific routes.py default_function = 'search' # ordinarily set in app-specific routes.py When I visit http://domain.com/ I receive the 'invalid function' page instead of rewriting to http://domain.com/my_app/default/search/. I'm debugging now and will post back when I learn more. -Mike On Aug 31, 2:04 pm, mwolfe02 <[email protected]> wrote: > This fixed the problems I was having. I'll let you know if I run into > anything else. > > Great work by the way...app-specificroutesare 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.
