On Jun 3, 5:14 pm, BenW <benwil...@gmail.com> wrote:
> I just posted a JSON-RPC handler I've been working with on the wiki:
>
> http://code.djangoproject.com/wiki/Jsonrpc
>
> I'd be interested in feedback from anyone doing async javascript with
> Django over RPC.
ben, hi,
there are many jsonrpc implementations. the best one i've found was
best modified by pimentech.fr and makes use of __call__ and
decorators, and makes it unbelievably simple to turn functions in a
module, or functions in a class, into a JSONRPC service.
JSONRPC is like the bedrock of pyjamas web 2.0 applications, and
django is the framework i use so i recommend it a _lot_. so, i've
made sure that the JSONRPC linkage between the two is the easiest
possible one i can find.
comparing the two implementations - see jsonrpc.py at:
http://groups.google.com/group/pyjamas-dev/files
[STOP at line 79 - ignore the FormsProcessor class]
the implementation you've written seems... clunky, by comparison.
there is an elegance to the jsonrpc.py that we're using.
you should have seen it before error handling and comments were added:
it fitted into about 35 lines of code! but, error handling and
traceback reports some people considered important enough to actually
kick them back to the web 2.0 application for display on-screen during
development, so the exception handling someone contributed (i think
someone on web2py group).
usage is utterly, utterly trivial:
from jsonrpc import jsonservice, jsonremote
jsonservice = JSONRPCService()
@jsonremote(jsonservice)
def test(request, echo_param):
return "echoing the param back: %s", echo_param
@jsonremote(jsonservice)
def add(request, x, y):
return x+y
save that in a file djangoapp/views.py - then you hand the jsonservice
instance to the urlpatterns:
(r'^service1/$', 'djangoapp.views.jsonservice'),
you can of course put @jsonremote(jsonservice) onto class methods as
well (i've never done that, preferring to design the module with
global functions, which are typically self-contained anyway, and the
use of a class is actually less efficient for no real gain).
one advantage of having the "request" parameter handed in is this:
the function is otherwise IDENTICAL to a quotes standard quotes django
view function. i've often converted "standard" django views over to
JSONRPC services with little effort required.
there are other advantages to passing in the initial "request" object,
such as being able to determine the IP address of the caller; access
to cookies etc. inside the JSONRPC function. for things like session
info - logins etc. - this is absolutely essential.
i do particularly like the report_smd() function that you've added,
btw. many people use GET on JSONRPC services and go "huh??" :)
also you (and others) may find this to be useful:
http://lkcl.net/jsonrpclib.tgz
it's a modified version of matt harrison's jsonrpclib code, which he
originally took from xmlrpclib. i've added error handling and tidied
it up a bit, and now use it to do unit tests on JSONRPC services.
one of the problems with web 2.0 development is that you're never sure
if the browser's buggered or your code is. or maybe the framework.
or you got the URL wrong. or you didn't understand XSS AJAX security
restrictions. having a python jsonrpc client helps eliminate many of
the things that could be wrong.
i'll be emphasising and talking about this in the pyjamas + django
tutorial at europython, if anyone's interested / attending.
l.
l.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
