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.
