Yeah, yeah, yeah.. My on-the-fly testing code wasn't correct. ;)
Checking with isinstance() is good but fails if params is just a string
due to the data.get('params', '') a few lines up.
Changing that to data.get('params', []) will resolve this or just drop
elif isinstance(params, list): and change it to an else: catch
||
ifisinstance(params,dict):
s =methods[method](**params)
else:
s =methods[method](*params)
This way the called method will take defaults or error out if variables
are not defined. Either way seems to work fine on my end.
Niphlod wrote:
> ok, let's try to not make any further confusion. Let's agree on what
> web2py needs to provide and how to call it.
> First things first: gluon.contrib.simplejsonrpc supports only 1.1, so
> *only* positional arguments sent as lists.
> jsonrpclib instead supports 2.0 spec, so *both* positional arguments
> sent as lists and keyword arguments sent as dicts.
>
> Second thing: it's hard to follow some example if the example is never
> going to work :P
>
> ||
> data =db(db.t_test.ALL).select()
> returndict(data=data)
>
> will go on exception no matter what.
> ||
> data =db().select(db.t_test.ALL)
> returndict(data=data)
>
> works as intended.
>
> Third: decorated functions usually need to have arguments.
> can we set on a
> ||
> @service.jsonrpc
> deftestlist(arg1,arg2):
> data =db().select(db.t_test.ALL)
> returndict(data=data,arg=arg1,arg2=arg2)
> ? Right!
>
> Now, I think with a simple patch we can escape the "pass parameters as
> a mapping or as a list" problem in gluon/tools.py
> ||
> ifisinstance(params,dict):
> s =methods[method](**params)
> elifisinstance(params,list):
> s =methods[method](*params)
>
> That should restore functionality for who calls functions only with
> "positional" style, while retaining the "keywords" style feature. This
> means that using contrib.simplejsonrpc you'll be able to call
>
> ||
> s.testlist(1,2)
>
> but not
> ||
>
> s.testlist(arg1=1,arg2=2)
>
>
> NB: This is just because simplejsonrpc adheres only to the 1.1 spec
>
> With jsonrpclib, however, both will work ok (yeah!)
>
> If this is fine, we can further fine-tune responses (e.g. 'version':
> '2.0' instead of 'version': '1.1') or having 2 separate @service
> decorators as Jonathan suggested.
>
> Do we have a deal ?
>
> --
>
>
>
--
- grutz;
--
