Ajax support, there is no need for reinventing the wheel
Jaroslaw Zabiello
0.95 now (svn) and still nothing was added. :(
Why? The idea is simple. Ajax is pain in ass if we would like to use
only pure JavaScript. So we need good helpers fo more comfortable work.
For me Rails has very cool Ajax support. They have even special
templates (rjs) for Ajax. It is very cool. But, the point is, that we
do no need to create it from scratch. Why? Because there is already
existing nice implementations of those helpers in Python! Another
pythonic framework - Pylons - is using it. Look at
http://pylonshq.com/WebHelpers/module-index.html. Why not to add these
libraries to Django? Why somebody would like to reinvent the wheel?
Matt McDonald
Hash: SHA1
I don't think "Ajax" should be included. Helpers like the ones in Rails
are encouraging bad design. Ajax should not be slapped onto a page to
make it look pretty, there are certain ways Ajax functionality should be
added to a page. For starters there shouldn't be a single character of
in-line Javascript on a page. Behavior should be separated from the
structure and obtrusive Javascript is bad. Using progressive enhancement
should be encouraged, so that means building the site without any
Javascript and then after the core functionality is working use
unobtrusive Javascript to enhance the content. Having "Ajax" "Helpers"
built into the framework will only encourage bad habits and bad coding.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEgQckviGJJnAgtcERAvvqAJ4+1sWeyooqllDcvWm3BL15nT+gRgCfR71t
P9uZ6usBHqamtDQWGFiOjZ4=
=Zqfe
-----END PGP SIGNATURE-----
Malcolm Tredinnick
So I had a look at this. Got confused. Looked again. Hmm.. here are a
few questions I have from looking at this for 30 minutes or so (and from
thinking about how XmlHttpRequest stuff might look previously):
It seems like only webhelpers.rails.prototype and
webhelpers.rails.srciptalicious are actually providing any kind of AJAX
(XmlHttpRequest) support, right? The tricky part of all this for Django
is working out how it would be *used* in Django. What do you add to your
templates, what other support is needed, ...? How can we make it
reasonably easy to use? There isn't really a clear proposal floating
around for what "adding AJAX to Django" really implies. Everybody has
some ideas, but it hasn't crystallised completely yet.
Please do correct me if I'm wrong, but the webhelpers package seems to
provide a UI for creating the HTML + Javascript that provides the "AJAX"
suport. And that UI that is not very Django-like as it stands, so it's
probably still a couple of steps removed from being drop-in useful. We
would have to put a wrapper over the top of these and, without doing an
in-depth evaluation of the work, I would wonder if wrapping the
Javascript libraries directly was more maintainable than wrapping a
wrapper of them. And does it require pre-requisites that we already have
elsewhere (e.g. does this portion of webhelpers depend on Routes, for
example?).
No concrete recommendations here, but I think this came across in the
original email as being easier than it really is. That being said, I
wouldn't mind seeing some support along these lines added to Django
eventually, since it adds value in some situations. But it isn't a
showstopper at the moment, I would have thought, and I would hope the
core pieces would always work without requiring AJAX at the moment. None
of which is ruled out by your proposal. So keep the discussion
going. :-)
Regards,
Malcolm
Bjørn Stabell
interface, and it totally makes sense there in order to provide a
better user interface as compared to standard HTML widgets.
I'm not sure why it still isn't merged in, though. I think it would
totally kick ass :)
Vladimir Pouzanov
> Ajax, in the form of Dojo, was slated to be added to the admin
> interface, and it totally makes sense there in order to provide a
> better user interface as compared to standard HTML widgets.
I don't know if you have same problems, but it seems that AJAX in Dojo
is not asynchronous. Both firefox and konqueror freeze until all the
data that's requested by Dojo js is loaded.
--
Sincerely,
Vladimir "Farcaller" Pouzanov
http://www.hackndev.com
Derek Hoy
It really simplifies the client-server ajax stuff. It lets you fetch
an object from the server and have it available in the client as a js
object, with properties and methods all available in your client code.
DWR serverside code generates the js files for download to the client
that handles all the marshalling stuff, so you don't see any of it.
It would make a great model for ajax support in Django. You call a DWR
js function, giving it a callback to your js function. This function
gets an object as a param, you use the object to fill bits of your
page etc.
--
Derek
James Bennett
> I don't know if you have same problems, but it seems that AJAX in Dojo
> is not asynchronous. Both firefox and konqueror freeze until all the
> data that's requested by Dojo js is loaded.
Dojo allows either synchronous or asynchronous calls to a server,
depending on the parameters passed to dojo.io.bind(). If you're seeing
something blocking until a server call completes, most likely it's
using a synchronous call.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
James Bennett
> I have heard that in Django 0.92 we will have added Ajax. We are having
> 0.95 now (svn) and still nothing was added. :(
So far as I know, no one, including myself (and I did the porting of
the admin JS to Dojo), ever laid out a specific version for "AJAX".
Making it easier to use AJAX with Django is certainly something that's
planned, but no-one can give you an exact date or version number for
it to happen at this point.
> Why? The idea is simple. Ajax is pain in ass if we would like to use
> only pure JavaScript. So we need good helpers fo more comfortable work.
> For me Rails has very cool Ajax support. They have even special
> templates (rjs) for Ajax. It is very cool.
In my opinion, it's not cool at all. Even setting aside the various
criticisms of Prototype (the JS library used by Rails), I think that's
much, much more than a good framework should provide.
I've said before, and I will say again, and I will likely keep saying
in the future, that I think Django would be best served by doing two
things:
1. Provide an easy way to make generic remote calls, most likely via
some sort of (hopefully RESTful) API. And not just remote calls from
JavaScript.
2. Provide a JavaScript library which can use the API we develop, but
keep the API well-documented so that people who want to talk to it
without using our library can do so.
Beyond that, I think tightly coupling Django to any particular JS
toolkit or way of using JS would be out of character for us; we should
make it easy for developers to use whatever techniques and tools they
prefer.
Also, it is extremely easy to do "AJAX" with Django right this very
minute; plug a generic view into a template that outputs XML or JSON,
and bingo, you've got AJAX.
Jay Parlar
getting really frustrated by one particular aspect:
In any view code that was only responding to async requests, if I had
a typo or error in my Python code (anything that would raise an
exception), I wasn't seeing any exceptions *anywhere*. Usually of
course, Django sends the exception information back to the client, to
be displayed on screen. Doesn't work so well when some JS is expecting
the response.
This was using the dev server and DEBUG=True. Maybe I missed something
in terms of how to get useful output, but it'd be nice if there were a
decorator or something that could tell Django that the client
expecting a response is *not* going to be able to display that
response, and the exception info should be displayed on the terminal.
Just my two cents,
Jay P.
Jeff Forcier
> This was using the dev server and DEBUG=True. Maybe I missed something
> in terms of how to get useful output, but it'd be nice if there were a
> decorator or something that could tell Django that the client
> expecting a response is *not* going to be able to display that
> response, and the exception info should be displayed on the terminal.
Well, assuming you implemented it with a simple 'RESTful'
ping-a-URL-and-get-something-back view method, you can easily debug it
by finding out what exact URL the JavaScript accessed (pretty sure
runserver tells you this on the console?), and manually going there in
your browser. Then you will see the normal Django error message. Took
me a short while to figure this out myself, probably because it was so
simple it didn't even occur to me at first =)
As for the general AJAX discussion, I agree wholeheartedly with
James--there's no need to tightly couple a given framework, especially
since good AJAX is exactly what he suggested and what I, at least, have
used successfully--the JS framework on one side and RESTful Django
views that return JSON or XML data on the other side.
Unless you (theoretical 'you', nobody specific) are doing something
extremely thorny (in which case you shouldn't expect the framework to
do everything for you *anyways*), this setup will work beautifully and
will make it super easy for people to use whatever JS framework they so
desire (I currently use Dojo, for various reasons).
Regards,
Jeff
Jay Parlar
>
> Jay Parlar wrote:
>
> > This was using the dev server and DEBUG=True. Maybe I missed something
> > in terms of how to get useful output, but it'd be nice if there were a
> > decorator or something that could tell Django that the client
> > expecting a response is *not* going to be able to display that
> > response, and the exception info should be displayed on the terminal.
>
> Well, assuming you implemented it with a simple 'RESTful'
> ping-a-URL-and-get-something-back view method, you can easily debug it
> by finding out what exact URL the JavaScript accessed (pretty sure
> runserver tells you this on the console?), and manually going there in
> your browser. Then you will see the normal Django error message. Took
> me a short while to figure this out myself, probably because it was so
> simple it didn't even occur to me at first =)
D'oh, I didn't think of that. However, in my particular case, it
wouldn't have worked, because I needed Session information that was
generated from previous views. Although I guess for debugging
purposes, I could have probably faked the Session part.
Jay P.
Vladimir Pouzanov
> Dojo allows either synchronous or asynchronous calls to a server,
> depending on the parameters passed to dojo.io.bind(). If you're seeing
> something blocking until a server call completes, most likely it's
> using a synchronous call.
I experience that trouble on all Dojo-powered sites including their
homepage. Anyway don't like a toolkit that locks my browser up even in
'official' way.
Jorge Gajon
>
> As for the general AJAX discussion, I agree wholeheartedly with
> James--there's no need to tightly couple a given framework, especially
> since good AJAX is exactly what he suggested and what I, at least, have
> used successfully--the JS framework on one side and RESTful Django
> views that return JSON or XML data on the other side.
>
I totally agree.
I certainly would not like to see more complexity added by bundling an
X or Y Ajax library. Better let the developer choose whatever js
library he wants.
I've been using MochiKit for the client side and SimpleJSON at the
server side which is extremely easy to use. And adding a
'/myobject/(\d+)/json/' url and view is dead simple. So far I don't
see any need to "Add AJAX support to Django", what support?
As for the bundled admin application, it is a "contributed"
application which could use any ajax library without, it shouldn't
introduce any complexity to "Django as a framework".
Cheers,
Jorge
Steven Armstrong
> On 6/3/06, James Bennett <ubern...@gmail.com> wrote:
>> Dojo allows either synchronous or asynchronous calls to a server,
>> depending on the parameters passed to dojo.io.bind(). If you're seeing
>> something blocking until a server call completes, most likely it's
>> using a synchronous call.
>
> I experience that trouble on all Dojo-powered sites including their
> homepage. Anyway don't like a toolkit that locks my browser up even in
> 'official' way.
>
Isn't that because of dojo.require loading libraries synchronously?
I believe if you prepackage all required libraries in one js file, which
the browser then can cache, it shouldn't be a problem.
At least that's my understanding of how it works.
James Bennett
> Isn't that because of dojo.require loading libraries synchronously?
I believe so.
> I believe if you prepackage all required libraries in one js file, which
> the browser then can cache, it shouldn't be a problem.
Yes.
James Bennett
> homepage. Anyway don't like a toolkit that locks my browser up even in
> 'official' way.
Every toolkit I've tried allows for synchronous requests, and the
implementations of XMLHttpRequest in browsers all allow for it.
Perhaps, then, you should just avoid AJAX altogether ;)
Scanner
Jorge Gajon wrote:
> I totally agree.
>
> I certainly would not like to see more complexity added by bundling an
> X or Y Ajax library. Better let the developer choose whatever js
> library he wants.
>
> I've been using MochiKit for the client side and SimpleJSON at the
> server side which is extremely easy to use. And adding a
> '/myobject/(\d+)/json/' url and view is dead simple. So far I don't
> see any need to "Add AJAX support to Django", what support?
>
> As for the bundled admin application, it is a "contributed"
> application which could use any ajax library without, it shouldn't
> introduce any complexity to "Django as a framework".
I agree that there does not seem to be any good reason to tightly
bundle django
with any such toolkit. However, it would be very nice to see various
people
that use django a lot present the methods that they think work best
with django.
Examples, a good guide, a set of recommenations, etc. It would really
help those
of us that are trying to figure out how we should use such toolkits
with django
instead of just saying "we do not need to do anything to django for
this.. "
oggie rob
yes, this would be good in the "reference" or "solving specific
problems" pages of documentation.
I also think the admin interface could benefit from some AJAX,
particularly things like autocompleting/autofiltering with the search
function in list views, and the way raw_id_admin is used. This would be
a great way to demonstrate some options without needing it to be part
of the core functionality.
-rob
Ian Holsman
I'd like django to pick a ajax toolkit and use it. (i don't care
which one it chooses)
Having no set standard makes it harder for people to share work, as
app ABC would use toolkit X, and app DEF would use another making it
hard to integrate other people's app/libraries into one project. (the
same reason i'd like to see a tagging app in the contrib section)
note: there is nothing forcing people to use that tookit, it will
just make it easier for a newbie coming into django with no specific
preference to get started and get his project running faster
regards
Ian
Honza Král
>
> my 2c's
and mine
>
> I'd like django to pick a ajax toolkit and use it. (i don't care
> which one it chooses)
I think this could be "solved" easily by creating a document (a
tutorial of some sort) "HowTo add AJAX framework XYZ to Django", so
that users that don't know/care about any framework would tend to use
XYZ, because that's what they have docs for. And that is "the official
way". I really believe that saying so is enough and no code is
actually needed in Django itself.
>
> Having no set standard makes it harder for people to share work, as
> app ABC would use toolkit X, and app DEF would use another making it
> hard to integrate other people's app/libraries into one project. (the
> same reason i'd like to see a tagging app in the contrib section)
>
> note: there is nothing forcing people to use that tookit, it will
> just make it easier for a newbie coming into django with no specific
> preference to get started and get his project running faster
>
agreed
> regards
> Ian
>
> On 04/06/2006, at 10:34 AM, oggie rob wrote:
>
> >
> >> However, it would be very nice to see various people that use
> >> django a lot present the methods that they think work best with
> >> django.
> >
> > yes, this would be good in the "reference" or "solving specific
> > problems" pages of documentation.
> >
> > I also think the admin interface could benefit from some AJAX,
> > particularly things like autocompleting/autofiltering with the search
> > function in list views, and the way raw_id_admin is used. This
> > would be
> > a great way to demonstrate some options without needing it to be part
> > of the core functionality.
> >
> > -rob
> >
> >
> > >
>
>
> >
>
--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
Honza Král
because even I wasn't able to understand what I meant... ;)
I will try to summarize my view:
create a document describing how to make framework XYZ talk to django
and vice versa
place it on the official site
any developer looking for an ajax framework to go with django will see
it and will likely use XYZ
He is not forced into it though and no modifications have to be done
to django itself to accommodate this.
HK
Vladimir Pouzanov
> which one it chooses)
What do you think about this: http://tinyurl.com/eeejh
tekNico
I don't know, I'm not going to click on a link that will redirect me
anywhere else. I don't like TinyURLs, the problems outweigh the
benefits.
tinyurl considered harmful
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0014.html
Risks of long and short URLs
http://catless.ncl.ac.uk/Risks/23.80.html#subj5
--
Nicola Larosa - http://www.tekNico.net/
If you can't answer a question within three steps,
you haven't designed the answers right.
-- Dratz, February 2006
Vladimir Pouzanov
>
> > What do you think about this: http://tinyurl.com/eeejh
>
> I don't know, I'm not going to click on a link that will redirect me
> anywhere else. I don't like TinyURLs, the problems outweigh the
> benefits.
iGL
http://groups.google.com/group/django-users/browse_thread/thread/104bc8a5cd447c68/5ecc2613eeca00fd?q=rails+ajax&rnum=3#5ecc2613eeca00fd
http://code.djangoproject.com/ticket/1262
Jeff Forcier
> Having no set standard makes it harder for people to share work, as
> app ABC would use toolkit X, and app DEF would use another making it
> hard to integrate other people's app/libraries into one project. (the
> same reason i'd like to see a tagging app in the contrib section)
>
> note: there is nothing forcing people to use that tookit, it will
> just make it easier for a newbie coming into django with no specific
> preference to get started and get his project running faster
You raise a good point. I think the problem here is twofold:
On the one hand, there's the concern of limiting choice, or appearing
to, by endorsing one framework. Doesn't matter if it's code integration
or just (un)official recommendation--people will still complain that we
"only support framework X". If we still care about pandering to
_complete_ newbies (see that ongoing thread in -devel) then this is a
valid thing to worry about.
On the other hand, there's the concern that shying *away* from picking
a framework to any degree, may scare off AJAX newbies confused by
either a lack of (Django-specific) AJAX docs, or a multitude of it for
varying frameworks.
I think the best solution, to echo what others have already said, is to
go the middle of the road and provide *solid*, *framework-agnostic*
docs that explain AJAX and how it would work with Django JSON/XML
views. By which I mean a good grounding in the basics of AJAX,
*without* examples from specific frameworks--which would make it more
akin to a tutorial than a learning experience.
Put the examples in a *second* document that intelligently contrasts
the varying frameworks in light of the principles outlined in the first
document--e.g. "Asynchronous requests: here's how Dojo does it, here's
how MochiKit does it, here's how Prototype does it...". Make sure that
newbies are essentially forced to read the first, generalized doc
before they can get much out of the second, and we'll have done as much
as we can.
Anyway, that's my two and a half cents; sorry for the verbosity and the
idealism :)
Regards,
Jeff
Scott Anderson
generates your Javascript to include" model really creates a lot of
problems, both with versioning and performance.
Simple is best. I've had the best luck with straightforward use of the
prototype.js Ajax class.
Regards,
-scott
Scott Anderson
the back-end.
You have to make sure to trap both successes and failures in the
Javascript code -- I don't know how mochikit does that, but with
prototype you need to specify an onFailure hook to get errors.
Regards,
-scott
James Bennett
> You have to make sure to trap both successes and failures in the
> Javascript code -- I don't know how mochikit does that, but with
> prototype you need to specify an onFailure hook to get errors.
And with Dojo the 'error' parameter you pass to dojo.io.bind() should
be a callback for error handling. Or if you just want one callback for
all responses, you can have your 'load' callback look at the
parameters passed to it to determine whether there was an error.
Simon Willison
On 5 Jun 2006, at 02:31, Scott Anderson wrote:
> You have to make sure to trap both successes and failures in the
> Javascript code -- I don't know how mochikit does that, but with
> prototype you need to specify an onFailure hook to get errors.
MochiKit models its async stuff on Twisted deferreds - which means
MochiKit callbacks end up looking like this:
var d = loadJSONDoc("example.json");
d.addCallback(gotDocument);
d.addErrback(logError);
You can also 'chain' callbacks and errbacks, which lets you do some
really interesting things.
Cheers,
Simon
Derek Hoy
>
> I'm sorry, but I can't agree. I've used DWR as well, and the "server
> generates your Javascript to include" model really creates a lot of
> problems, both with versioning and performance.
>
> Simple is best. I've had the best luck with straightforward use of the
> prototype.js Ajax class.
>
> Regards,
> -scott
Well, that wasn't my experience.
Anyhow, I agree with the mood in the group to not build this kind of
stuff into Django. I'm using Django because it's relatively lean and
mean.
The idea of having tutorial stuff on using X with Django is a good way to go.
--
Derek
wiz
templates? We couldn't just slap to <head></head> one or another
pretty ajax lib? Looks like this is the question of lazyness.
I'm pretty happy now with my tiny jah.js + data from generic views and
heard about some nice ajax packages. So what is this buzz about?