Does Djange support Ajax to the same extent as TurboGears?
walterbyrd
does. I don't know if TurboGears has any features that make it more
Ajax friendly.
Adrian Holovaty
My suggestion would be to build a quick application with both
frameworks and use the one that feels more natural to you. Both
frameworks will let you get the job done, but they have different
philosophies. TurboGears' philosophy is closer to that of Linux,
valuing the interoperability of obscure parts at almost a
religious/political level, with predictable results in terms of
usability and elegance. Django's philosophy is closer to that of a
Mac, which values usability, productivity and a great user experience
while allowing for a fair amount of flexibility under the hood.
At the end of the day, it's a personal decision. Good luck!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Jeremy Dunck
TurboGears does provide more features in relation to ajax. These
features trade coupling for convenience. Where it works, this is
useful, but it's not a trade-off Django is making.
Eric Walstad
/me runs, screaming something about GTFW, from the mailing list. ;)
James Bennett
It depends on your definition of "AJAX support" :)
If you mean "the framework writes your JavaScript for you", then no,
Django doesn't.
If you mean "the framework makes it easy to read XMLHttpRequests and
respond with XML or JSON", then yes, Django does.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
igor Guerrero
And the comparison between Linux and Mac... heee let's not talk about it because it can be
a War!!!! :P, for me Linux is like Django simply they are Best
Jeremy Dunck
> respond with XML or JSON", then yes, Django does.
def ajaxy_data(request, south, west, north, east):
....
return HttpResponse("handleData(" + simplejson.dumps(ret) + ");")
Mmm. That's nice Ajax support. ;-)
gabor
> On 11/19/06, walterbyrd <walte...@iname.com> wrote:
>> TurboGears seems to "advertise" their support of Ajax more than Django
>> does. I don't know if TurboGears has any features that make it more
>> Ajax friendly.
>>
>
> TurboGears does provide more features in relation to ajax.
(wow, finally someone with info :)
hi,
please, please, pretty please tell me/us, what ajax-features does
Turbogears have?
gabor
Jeremy Dunck
>
> (wow, finally someone with info :)
>
> hi,
>
> please, please, pretty please tell me/us, what ajax-features does
> Turbogears have?
See, for example,
http://docs.turbogears.org/1.0/JSON
Waylan Limberg
Then see: http://www.djangoproject.com/documentation/serialization/
I realize it's currently still under development and therefore doesn't
have a direct link from the doc page, but it is there and works.
>
> >
>
--
----
Waylan Limberg
way...@gmail.com
Kenneth Gonsalves
On 20-Nov-06, at 10:07 PM, Adrian Holovaty wrote:
> ill let you get the job done, but they have different
> philosophies. TurboGears' philosophy is closer to that of Linux,
> valuing the interoperability of obscure parts at almost a
> religious/political level, with predictable results in terms of
> usability and elegance. Django's philosophy is closer to that of a
> Mac, which values usability, productivity and a great user experience
> while allowing for a fair amount of flexibility under the hood.
i wish you hadnt said this. Are you talking about the linux kernel
development model or about linux distributions? As far as i can see,
django follows the bazaar model of development, also followed by the
linux kernel development. It also seems to me that django is
following the route of small incremental development rather than a
grand master-planned strategy. No one but apple knows what model the
mac follows. I could agree with you if you had said:
linux:bsd = turbogears:django. But this is not the crucial
difference. Django is born of the sell it, free it model, proven in
production as response to a real need, whereas turbo-gears is born of
scratching and itch, hence more of a hobbyist tool. This is the real
difference. An interesting statistic - about a year back,
#rubyonrails had 400 members, #django and #turbogears had around 45
each. Today #django averages around 160 whereas the other two are at
the same number.
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
comechao
( i'm YUI and jQuery happy user :D ).
gabor
and please note, that (if i'm reading it correctly) it's something
different.
the django-serialization serializes a django-object.
the turbogears-json (at least the one linked from this mail) simply
json-serializes a dictionary. that's MUCH simpler.
in django you would probably do:
> from django.utils.simplejson import dumps
>
> def myview(request):
> res = {'a':2,'b':3}
> return HttpResponse(dumps(res),mimetype='application/json')
or, we can even write a decorator, like:
> def json_wrap(func):
> def _json_wrap(*args, **kwargs):
> return HttpResponse(dumps(func(*args,**kwargs)),mimetype="application/json")
> return _json_wrap
and then you can use it like:
> @json_wrap
> def foo(request,a,b,c):
> return dict(a=a,b=b,c=c)
p.s: there might be errors in the source code ,but the idea should work
gabor
James Bennett
> and please note, that (if i'm reading it correctly) it's something
> different.
>
> the django-serialization serializes a django-object.
>
> the turbogears-json (at least the one linked from this mail) simply
> json-serializes a dictionary. that's MUCH simpler.
Yes and no.
The JSON serializer is meant for serializing Django model instances,
because there are some particular quirks which need to be handled
correctly. So if you have a QuerySet or a list of model instances, the
serializer is the way to go. For any other type of data, plain old
'simplejson.dumps()' will work fine, and simplejson is bundled in
Django (at django.util.simplejson).
gabor
> On 11/21/06, gabor <ga...@nekomancer.net> wrote:
>> and please note, that (if i'm reading it correctly) it's something
>> different.
>>
>> the django-serialization serializes a django-object.
>>
>> the turbogears-json (at least the one linked from this mail) simply
>> json-serializes a dictionary. that's MUCH simpler.
>
> Yes and no.
>
> The JSON serializer is meant for serializing Django model instances,
> because there are some particular quirks which need to be handled
> correctly. So if you have a QuerySet or a list of model instances, the
> serializer is the way to go. For any other type of data, plain old
> 'simplejson.dumps()' will work fine, and simplejson is bundled in
> Django (at django.util.simplejson).
>
i'm sorry, but which part of my mail is referred by the "no" ? :)
gabor
James Bennett
> i'm sorry, but which part of my mail is referred by the "no" ? :)
'Yes' in that the TurboGears stuff works on any dictionary and the
Django serializer class only works on lists of model instances. 'No'
in that we bundle simplejson so you have a way to dump any Python
value to JSON :)