On Sep 2, 2010, at 6:40 AM, mwolfe02 wrote: > > Actually, I had commented out routes_app altogether. When I restored > it to this, things seemed to work again: > > routes_app = ((r'/(?P<app>welcome|admin|examples|app)\b.*', > r'\g<app>'), > (r'(.*)', r'my_app'), > (r'/?(.*)', r'my_app')) > > I was thinking that the logic would work as follows: > > 1. if base routes_in exists check URL against base routes_in (if match > found then rewrite else continue) > 2. if routes_app exists check URL against routes_app (if match found > then load app-specific routes_in or app-specific default controller/ > function else continue) > 3. if default_app specified then load app-specific routes_in or app- > specific default controller/function for the default_app > 4. if no default_app specified and URL does not match base routes_in > or routes_app return error
First of all, default_* doesn't really have anything to do with rewriting. I added them to routes.py as a convenience, to be able to override the default init/default/index logic that happens after all the routes_in is complete. I would recommend using routes_* or default_*, but not both. routes_app is the first thing we look at. It completely determines which routes.py (base or app-specific) we'll use for the entire request and response. If there's no routes_app, then we'll always use the base routes.py. So the rule is actually pretty simple: 1. If routes_app produces an application name, and that application has its own routes.py, then use that app-specific routes.py. In all other cases, use the base routes.py. (This decision is final for the entire request.) 2. Using the routes.py determined in (1), apply routes_in to the URL. The best practice, in my view, is for routes_in to always product a complete URL (a/c/f/...). 3. If the URL does not have all three routing elements /a/c/f, complete it with default_* from the selected routes.py (defaulting in the code to /init/default/index if not overridden). 4. All subsequent rewriting (routes_out, error rewriting, etc) uses the routes.py selected in (1). Note that an app-specfic routes.py is all or nothing. If (1) selects an app-specific routes.py and that routes.py does not contain (say) a routes_out, we do *not* fall back on the base routes_out. Similarly for default_*. > > > Once URL rewriting has been redirected to a specific app (as in step 2 > or 3 above) do the following: > > 1. if app-specific routes_in exists check URL against app-specific > routes_in (if match found then rewrite else continue) > 2. if URL maps to an existing controller/function, then call that > controller/function else continue > 3. if default_controller specified, prepend default_controller to URL > and try step 2 else continue > 4. if default_controller and default_function specified, prepend > default_controller/default_function to URL and try step 2 else > continue > 5. if default_function specified, assume first part of URL is > controller, insert default_function after assumed controller and > before any potential function arguments > 6. if nothing matches, return error > > Obviously my assumptions were not entirely correct. I'm wondering if > you could pass along a brief overview of how the routes_app, > default_app, default_controller, and default_function parameters all > actually do interact in terms of URL rewriting. > > Thanks again, > -Mike > > On Aug 31, 5:34 pm, Jonathan Lundell <[email protected]> wrote: >> On Aug 31, 2010, at 2:20 PM, Michael Wolfe wrote: >> >> >> >> >> >> >> >>> That didn't seem to quite do it. Visitinghttp://domain.com/rewrites >>> tohttp://domain.com/my_app/default/index/instead of >>> http://domain.com/my_app/default/search/. The URL is being >>> substantively rewritten in the parse_url function (lines 802-807) of >>> gluon/main.py: >> >>> request.application = \ >>> regex_space.sub('_', match.group('a') or >>> rewrite.params.default_application) >>> request.controller = \ >>> regex_space.sub('_', match.group('c') or >>> rewrite.params.default_controller) >>> request.function = \ >>> regex_space.sub('_', match.group('f') or >>> rewrite.params.default_function) >> >>> The problem being that rewrite.params.default_function is not using >>> the default_function specified in my app-specific routes.py. >> >>> The parse_url function is being called from line 326 of gluon/main.py: >> >>> # ################################################## >>> # invoke the legacy URL parser and serve static file >>> # ################################################## >> >>> static_file = parse_url(request, environ) >> >>> To be clear, /my_app/default/search/ is not a static file; parse_url >>> appears to do double-duty identifying static files and performing >>> simple URL re-writes. >> >>> On a side note, I'll be heading home for the day soon and won't be >>> working on this project again until Thursday. So if you don't get a >>> response from me for awhile....that's why. >> >> OK. I'll take a closer look. It's helpful to know that it's getting 'index' >> in this case. >> >> One final thing: what's your routes_app? Ishttp://domain.com/resulting in >> my_app? Maybe you could send me, privately if you like, your global and >> my_app routes.py. >> >> >> >> >> >>> -Mike >> >>> On Tue, Aug 31, 2010 at 4:09 PM, Jonathan Lundell <[email protected]> >>> wrote: >>>> On Aug 31, 2010, at 12:53 PM, mwolfe02 wrote: >> >>>>> 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 visithttp://domain.com/I receive the 'invalid function' page >>>>> instead of rewriting tohttp://domain.com/my_app/default/search/. I'm >>>>> debugging now and will post back when I learn more. >> >>>> OK, making the current app the default turned out to be pretty >>>> straightforward, and even if that's not the problem you're having, I think >>>> it makes sense to do. Here's the new rewrite.py: >> >>>> http://web.me.com/jlundell/filechute/rewrite.zip
