On Sep 2, 2010, at 7:40 AM, Michael Wolfe wrote: > > Great info. Thanks for taking the time to explain.
You're welcome. A caveat: I don't believe that the current logic is thread-safe. Consequently, if you have simultaneous requests on different threads that use different routes.py files, one of them could end up using the wrong logic for some or all of its translations. I intend to fix it, but I haven't figured out how yet. So if you're using multiple apps in production, I recommend sticking to the base routes.py for now. > > -Mike > > On Thu, Sep 2, 2010 at 10:16 AM, Jonathan Lundell <[email protected]> wrote: >> 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 >> >> >>
