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.
