No worries. I'll find a workaround. This is just behavior of the routes.py layer, nothing more. Everything I showed you above was done with a debugger stopping execution at the point where "default/auth_search" was called. I showed the url and args before any execution of the routine itself. Only routes.py was involved, not my code at all. The call was always made to "/swim_smarter/default/auth_search/contents" in each case but handled by routes.py (and maybe URL()) differently.
Honestly I've always thought routes.py was a little mysterious and "magical" and I don't like relying on magic for a deployed website. So learning url-rewriting in Apache is probably the best thing to do long term anyway. Warm regards, Joe On Sunday, October 9, 2016 at 5:08:22 PM UTC-7, Anthony wrote: > > I would recommend either attaching an app and routes.py that reproduces > the problem, or describing precisely how to replicate, as it is not clear > exactly what you are doing. If the problem is unrelated to your special > class, then just exclude that. > > Anthony > > On Sunday, October 9, 2016 at 4:24:48 PM UTC-4, Joe Barnhart wrote: >> >> I pulled the request.url and request.args BEFORE my app was called. This >> is exactly as my app sees it before any processing. >> >> The problem is that I get the "args" in one case but not in the other, >> depending entirely on routes.py. >> >> Even without any code from me at all, you could see the same effect with >> stock web2py. My code is malfunctioning, to be sure, but the cause of its >> malfunction is the difference between using routes.py or not. >> >> At this point, I'm wondering what alternatives I have w/respect to not >> using routes.py at all. Maybe I can use apache url rewriting to accomplish >> the same thing with more consistency. I'm not really an apache expert, but >> it looks like I'm gonna have to learn more about it! >> >> -- Joe >> >> >> On Sunday, October 9, 2016 at 9:26:51 AM UTC-7, Anthony wrote: >>> >>> For the actual requested URL, you want request.env.request_uri -- or >>> better yet, look at the outgoing request from the browser network tab. >>> >>> Not sure where you are checking for request.args in that code, but in >>> your __call__ method you have ra.pop(0), so at that point, you have deleted >>> the first URL arg from request.args -- it won't be there for any subsequent >>> references to request.args(0). >>> >>> I don't think we have the full picture here, as we're missing a lot of >>> the code. You might have to attach a minimal app (with routes.py) that >>> replicates the problem. >>> >>> Anthony >>> >>> On Sunday, October 9, 2016 at 3:40:15 AM UTC-4, Joe Barnhart wrote: >>>> >>>> Here is the actual URL called and args passed. The "auth-like" >>>> function is auth_search and the argument should be "content" >>>> >>>> current.request.url >>>> '/default/auth_search/content/' >>>> current.request.args >>>> [] >>>> >>>> Or, with no routes.py, we see the application 'swim_smarter' come to >>>> the fore and now the args are passed. >>>> >>>> current.request.url >>>> '/swim_smarter/default/auth_search/content/' >>>> current.request.args >>>> ['content'] >>>> >>>> So let's try with routes.py but with no listing of "default" as the >>>> default controller >>>> >>>> current.request.url >>>> '/default/auth_search/content/' >>>> current.request.args >>>> [] >>>> >>>> I'm using the URL function to create the URL in all cases. >>>> >>>> When I say it "fails to work" I mean it leaves the request.args empty, >>>> and my magic function never invokes one of the sub-functions. Thus it >>>> passes back the entire page created by the widget function of the default >>>> controller. So it got a bunch of HTML when all it expected was some JSON >>>> from my sub-function. >>>> >>>> On Saturday, October 8, 2016 at 6:27:40 AM UTC-7, Anthony wrote: >>>>> >>>>> On Friday, October 7, 2016 at 11:29:36 PM UTC-4, Joe Barnhart wrote: >>>>>> >>>>>> I created some "widgets" (for lack of a more descriptive name) using >>>>>> the same pattern as the Auth object. When you call it, it returns a >>>>>> special function that can respond to several different "sub-functions". >>>>>> This has been tremendously handy but now I'm encountering a problem -- >>>>>> when I uses this in my "default" controller it fails to parse its >>>>>> sub-function properly. >>>>>> >>>>>> Here is the code, patterned after Auth: >>>>>> >>>>>> def __call__(self): >>>>>> from gluon.http import HTTP >>>>>> request = current.request >>>>>> ra = request.args >>>>>> if not ra: >>>>>> return self.widget() >>>>>> if ra[0] in self.api: >>>>>> return getattr(self, ra.pop(0))() >>>>>> else: >>>>>> raise HTTP(404) >>>>>> >>>>>> The above code lives in a module, not a controller. The method >>>>>> self.widget() just returns a dictionary that contains the html and >>>>>> so forth, for building the presentation of the widget. The instance var >>>>>> self.api contains a list of "sub-functions" that, when called, will >>>>>> return something different than the widget() function. Usually this >>>>>> is some sort of ajax function or other script-y thing that is called >>>>>> from >>>>>> the widget. >>>>>> >>>>>> My problem lies in the request.args[]. When called from any >>>>>> controller but my default, everything works perfectly. The calling URL >>>>>> looks something like: >>>>>> >>>>>> /big_app/default/widget/sub_function/whatever >>>>>> >>>>> >>>>> How are you generating that URL? With the router, presumably it should >>>>> just be /widget/sub_function/whatever, no? >>>>> >>>>> Also, what do you mean that it fails to work? Exactly what happens? >>>>> >>>>> We may need to see more code. >>>>> >>>>> Anthony >>>>> >>>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
