This Ajax example has been written in 2006 and therefore it is slowly falling behind the technology curve. A good deal of html interaction could be done more elegantly with jquery. That is the javascript library that I would use today (May 2008) to implement the same functionality.

Note 2: Make sure to read the security notice at the end of this page.

The following is an AJAX demo developed as a means of learning about this technology. There are two versions of the demo with different javascript libraries Prototype and MochiKit. The target use case was the so called in-place-editing, creating and submitting a form without leaving the page.

step 1	step 2	step 3

AJAX calls are made for both populating and saving the text area, feedback messages are displayed while the data is being fetched and saved. In a nutshell the approach works by assigning IDs for all the HTML tags (DOM elements) that need to be interacted with. As you'll see there are quite a few to keep track of. But once one forms a picture of what needs to be displayed at which stage, it simply becomes a matter of creating, removing hiding or showing these elements.

Files to look at:

• the main django view views.py
• the javascript actions using prototype proto-actions.js
• the javascript actions using the mochikit library mochi-actions.js

As far as this demo goes the most notable difference seems to be in the way HTML elements are generated. The prototype based approach pieces the DOM elements toghether from strings, while mochikit can generate them with functions ... (it might just also be that I was unable to discover some functionality in prototype). The MochiKit approach resulted in cleaner code ... on the other hand I did it second and by that time I already had a good sense of what I was trying to do. I'll probably be using this latter though, one of its quite unique features (not shown here) is a logging capability that turns out to be a great timesaver.

Get the full source here: ajax-sandbox.zip To run the demo you'll need to have django present. You may need to edit the run.bat or run.sh script files so that the django module appears in the python path.

Send feedback, comments or corrections to istvan.albert@gmail.com , cheers.

---- SECURITY NOTICE ----

Luke Plant has recently sent me the following email

On this page:

http://www.personal.psu.edu/iua1/ajax-django-sandbox.htm

the code you present has some security serious problems:

1) You use GET for saving data instead of POST. GET should never be used
for requests that have side effects - see:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

2) Further, this produces a security problem.  Django has plug-in
protection for CSRF attacks (not yet enabled by default, but will be
soon), but by design it only protects against POST requests, due to
point 1).  Your code would open a JSON backdoor that isn't protected
against CRSF into someone's application that would otherwise be safe.

I know that it is only demo code, and that you don't have any
authentication at all in the example (in which case CSRF wouldn't be a
concern anyway), but demo code that encourages bad practice or leads to
security vulnerabilities if it is used as a basis for people's work is
a bad idea, and at the very least it should have a big warning notice
on it.

From the look of your code, once you convert it to use POST it would
require some additional work to satisfy the CSRF protection (not much -
you would simply have to get the csrfmiddlewaretoken and include it
with the data that is submitted).  For the sake of the demo, I would
just convert it to POST, and add a notice that satisfying Django's CSRF
protection will require a bit of extra work.

(Due to the same origin policy, there is another way to add protection
(set the 'Content-Type' on the request to something
like 'application/json', and require it to be present in the Django
view), but this is a bad idea if you are already using Django's CSRF
protection, I won't bore you with the details)

Thanks for putting up the demo code, BTW,

Regards,

Luke