Feel free to open a Github issue, or better yet, send a pull request. Depending on your use case, another option is to instead decorate the call() action in order to pass in extra args (you can strip them out of request.args and request.vars before the service method gets called).
Anthony On Wednesday, January 11, 2017 at 11:01:56 PM UTC-5, Brendan Barnwell wrote: > > On Thursday, January 5, 2017 at 7:04:56 AM UTC-8, Anthony wrote: >> >> But from the other side of things, I guess the question is, if we can do >>> that, is there ever any reason to use the "service" mechanism at all? Or >>> can request.restful do everything service can do, and more? >>> >> >> I suppose their use cases are overlapping. If @request.restful works for >> you in this case, then use it. The @service mechanism lets you easily >> expose functions for use in remote procedure calls, including via >> standardized RPC protocols. The @service decorators also automatically >> return the correct response format, whereas @request.restful requires the >> use of the generic views (disabled by default) to automatically generate >> different response formats (though it will automatically generate JSON if >> the request specifies "application/json"). >> >> Anthony >> > > > I guess the request.restful approach works better for me at this point. > Is there a way to tell web2py to enable generic views only for restful > controller functions, and disable them otherwise? > > In continuing to explore both approaches, I gained a better understanding > of my problem with the service approach, and I want to share it here > because I think it is worth thinking about in terms of the design of > web2py. The problem I have with the service approach is that it seems to > make impossible to use a decorator to wrap a service controller function in > order to add or remove arguments, because the service function will "block" > web2py from seeing what arguments the real service function accepts, > causing web2py to pass the wrong arguments. > > There is a certain Python idiom that goes something like this: > > def accept_extra_arg(func): > def wrapper(extra_arg, *args, **kwargs): > # maybe do something with extra_arg here > result = func(*args, **kwargs) > # maybe do something with extra_arg here > return result > return wrapper > > @accept_extra_arg > def foo(x, y): > return x+y > > The idea is that the accept_extra_arg decorator allows you to wrap your > function with a handler that accepts an extra argument which the function > does not see, but which is used to preprocess the function's arguments > and/or postprocess its result. In the case of web APIs, for instance, this > is a natural way to do something like write a series of API functions that > require an API key to be used: you can have a @requires_key decorator that > wraps functions, allowing the function itself to be "pure" and just > concentrate on returning the data, without having to handle the checking of > the API key. There is a related idiom which is the reverse, involving > writing a decorator that accepts an argument and returns a decorated > function accepting *fewer* arguments that the original, allowing a behavior > akin to functools.partial, by which some arguments are specified in advance > via the decorator, rather than being passed on each call to the decorated > function. > > The web2py service mechanism breaks this idiom. The problem is that > because the wrapped function is supposed to be agnostic as to the arguments > of the function it wraps, it just accepts *args and **kwargs (in addition > to its extra argument). This means that web2py won't pass it anything. > This kind of breaks the RPC idea that calling the function internally > should be the same as calling it via the network API: if my function wants > to use *args and/or **kwargs, web2py apparently doesn't provide a way for > me to use it in a seamless manner for internal vs external calls. > > I *think* I have been able to get around this with request.restful, > because it passes everything along without trying to match the arguments. > But it is somewhat annoying for the case of read-only APIs because of the > extra layer of indirection required (returning a function that returns the > data, rather than just returning the data). > > What I really want is the ability to write an arbitrary function, > accepting arbitrary arguments. I want the ability to wrap that function > with decorators that absorb or add arguments as I please. And then I want > to be able to expose that arbitrarily wrapped function as a service > endpoint (presumably by wrapping the function with a web2py decorator as > the last one). I don't want any of the decorators nor the original > function ever to have to worry about *how* the arguments are being passed > (e.g., positionally or by keyword), and I don't want any function in the > chain to ever have to worry about the number or names of any arguments > other than the ones it explicitly processes from the arguments passed to > it. So, basically, I want to be able to use decorators the same way I > would use them in ordinary Python code, and not have web2py step in at some > point and disrupt the process by which decorated functions pass their > arguments to the functions they wrap. > > Now, that's not to say that I don't appreciate the tools web2py does > offer. I've found them quite powerful. And for now I think I can make > things work with the restful decorator. But just mention above to maybe be > considered for future web2py development. The ability to manipulate > function signatures with decorators in a way that remains transparent from > the perspective of the wrapped functions is a really nice feature of > Python, and the ability to use varargs is powerful too, and I think it > would be good for web2py to allow such functions to be exposed without > sacrificing those features of Python. > -- 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.
