ajax and json
Huy Do
Is there some sort of controller -> json -> ajax layer at the moment ?
Is pylons planning to provide some sort of json output automatically
from the stuff in the "c" object ?
Thanks
Huy
Ben Bangert
There is a JSON decorator that comes with Pylons which will return
the output of your action as JSON.
http://pylonshq.com/docs/module-pylons.decorators.html
To use it, you'd have your decorator return data that the simple json
package can turn into JSON data. Since the c object is doing some
special thread-local stuff to make it available, it's currently a
little more tricky to return it properly. Here's what a simple
controller returning JSON looks like:
from pylons.decorators import jsonify
class YourController(BaseController):
@jsonify
def index(self):
c.name = "Bob"
c.house = "123 Elm St"
return c._local.request
The c access as I noted is a little extra effect as we have to go to
the actual dict its using to store your data for the request duration.
Alternatively, what you might be thinking, which we can do in the
future, is to have a JSON decorator, that will look to see if you
have #json or something on the end of your URL (like how TurboGears
does it), and will then intercept template rendering, to ensure that
only the JSON contents of c are returned.
Hope that helps,
Ben
Medium
Ben Bangert wrote:
> On Feb 9, 2006, at 1:42 PM, Huy Do wrote:
>
> > Is there some sort of controller -> json -> ajax layer at the
> > moment ? Is pylons planning to provide some sort of json output
> > automatically from the stuff in the "c" object ?
>
> There is a JSON decorator that comes with Pylons which will return
> the output of your action as JSON.
> http://pylonshq.com/docs/module-pylons.decorators.html
>
> To use it, you'd have your decorator return data that the simple json
> package can turn into JSON data. Since the c object is doing some
> special thread-local stuff to make it available, it's currently a
> little more tricky to return it properly. Here's what a simple
> controller returning JSON looks like:
>
> from pylons.decorators import jsonify
>
> class YourController(BaseController):
> @jsonify
> def index(self):
> c.name = "Bob"
> c.house = "123 Elm St"
> return c._local.request
Thanks Ben, thats exactly what i was looking for.
> The c access as I noted is a little extra effect as we have to go to
> the actual dict its using to store your data for the request duration.
>
> Alternatively, what you might be thinking, which we can do in the
> future, is to have a JSON decorator, that will look to see if you
> have #json or something on the end of your URL (like how TurboGears
> does it), and will then intercept template rendering, to ensure that
> only the JSON contents of c are returned.
This would be ideal.
> Hope that helps,
> Ben
Sure does, thanks again.
Huy
Kendall Clark
On Feb 9, 2006, at 5:04 PM, Ben Bangert wrote:
> Alternatively, what you might be thinking, which we can do in the
> future, is to have a JSON decorator, that will look to see if you
> have #json or something on the end of your URL (like how TurboGears
> does it),
Eww! Don't do that. :>
The semantics of fragment identifiers are per MIME type, not per
application. That is, what U#foo means depends on the Internet Media
Type that one gets back when you GET U. #foo means different things
in XML or XPointer or RDF or etc.
See the W3C's Web Architecture or HTTP RFC for more details. The way,
it seems to me, to do this is with HTTP content negotiation where the
client requests JSON serialization of some resource using Accept:
headers.
Cheers,
Kendall Clark
huydo
Kendall Clark wrote:
> On Feb 9, 2006, at 5:04 PM, Ben Bangert wrote:
>
> > Alternatively, what you might be thinking, which we can do in the
> > future, is to have a JSON decorator, that will look to see if you
> > have #json or something on the end of your URL (like how TurboGears
> > does it),
>
> Eww! Don't do that. :>
>
lol....
> The semantics of fragment identifiers are per MIME type, not per
> application. That is, what U#foo means depends on the Internet Media
> Type that one gets back when you GET U. #foo means different things
> in XML or XPointer or RDF or etc.
>
> See the W3C's Web Architecture or HTTP RFC for more details. The way,
> it seems to me, to do this is with HTTP content negotiation where the
> client requests JSON serialization of some resource using Accept:
> headers.
>
> Cheers,
> Kendall Clark
Sounds good but which ever way this is done, it should be as
transparent as possible to the controller code. That way we can reuse
the controller actions for as many different front ends as possible
(plain html, ajax, xul etc. etc.)
Huy