Good to know.
On Thu, Sep 2, 2010 at 10:58 AM, Jonathan Lundell <[email protected]> wrote: > 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 >>> >>> >>> > > >
