On saturday I gave a little session there about the JavaScript Framework Dojo and the server-side web framework Django and how you can use Dojango to combine those two worlds. In the session I’ve showed some basic slides that were followed by a simple coding example. The people, who attended my session, were more interested in Dojo instead of Django, because they already knew a lot of Django. After doing my 30 minutes for the session I had to answer Dojo questions for another half an hour. Next time I definitely will do a Dojo session upfront :-)

Thanks to the organizers and sponsors for having such a nice event in Cologne. Can’t wait for attending the next BarCamp there.

1) Amsterdam, 27th April, 19:00 – the first one will be already next week in Amsterdam on Monday the 27th April, this will be a meetup in a restaurant and probably a lot of tech and geek talk and some beer.

2) Munich, 9th May, all day – the second one will be a free full-day event in Munich with talks and time to hang out and hack together. It will take place on the 9th May, starting at around 12:00 in the rooms of the SKYTEC AG (Keltenring 11, 82041 Oberhaching).

Amsterdam, 27th April

Detailed information
All the following info are from the dojocampus.org post.

The first dojo.beer() in The Netherlands will be held on April 27th in Amsterdam. Hopefully this will be the beginning of a series of fun Dojo events bringing people from The Netherlands and around together, who work with Dojo, enjoy using Dojo and like everything around the Web.

As a special guest we will have both Dylan Schiemann (SitePen, Dojo Co-Founder) and Peter Higgins (Dojo Project Lead – aka phiggins), so if you want to meet the gurus of Dojo, make sure you will be there.

Location and more details will follow shortly.

Munich, 9th May

Detailed information
After the very well received dojo.wine in Würzburg with 37 attendees we hope we can do even better and will fly in Pete and Dylan to join us (so we don’t have to video-conference them in anymore). We are happy to have the Skytec AG sponsoring the location.

There are some really interesting topics planned, that are not only interesting for the dojo people but also for other JavaScript developers and developers of complementary technologies, such as django, comet(d), etc.

• dojango – dojo and django integration made easy
• xray – a JavaScript+browser performance and analyzing tool
• EventList – a google calendar, yahoo pipes mashup
• Stocker – SitePen’s cometd based chart and grid application
• plugd – a collection of useful functionality built on and around Base dojo.js

If any of this catches your eye we will be happy to see you there. Please add yourself to the event wiki page so we can better plan and prepare the event. Also if you have a talk you would like to give or there are topics that you are potentially interested in, please fill it in the wiki.
And of course we will have T-Shirts, stickers, food, drinks and so on. We are looking forward to seeing you there.

Professional Training, 8th May

If you or your employees need a packed dose of professional dojo training, you can still signup for the uxebu & SitePen – Dojo training in Europe. This training takes place in the same location as the dojo.beer, just the day before, on the 8th May.
This one day course on Dojo Data, Grids, Charts, and Comet is a very practical, hands-on, applied usage of Dojo to create a simple data visualization web application that takes advantage of advanced features of the Dojo Toolkit.

At the moment AppEngine just supports version 0.96 (see Google AppEngine Helper for Django) of Django and dojango is now able to run with this old version.

Since dojo’s variety of modules easily excesses the limitation of Google’s AppEngine of 1000 files, dojango now can solve this problem with an extreme mini build that just keeps the basic dojo files and all image files. I have to mention that this build removes all js-files that could be postloaded on a page using dojo.require. This means, that a dojo.require on Dojo modules that weren’t included in the Dojo build profile would not work anymore. So, when using the extreme mini build, you have to add all Dojo modules, that are used within the deployed application, to your Dojo build profile.

I’ll show the deployment to AppEngine of a dojango application and the building of a Dojo release with the extreme mini build in another blog entry.

Dojango 0.3.1 also had some other changes, like the addition of Dojo 1.2 as the new default Dojo version for dojango and Google is now used as the default CDN instead of AOL.

Also two new decorator functions found their way into dojango.

One is the json_iframe_response decorator that makes it easier to return json data when dojo.io.iframe is used. dojo.io.iframe is utilized e.g., if you want to submit multipart/form-data forms with file fields in the background. Here is a simple example, how to use that decorator:

The Django side:

The Dojo side:

The other decorator jsonp_response can enable django views to deliver json data to foreign web applications using JSONP. You need that, if you want to make several django views available as your external API. Here is a short usage example:

The Django side:

The Dojo side:

For the next release we planned to take JSON-RPC, SMD (Simple Method Description) and maybe CometD into account. If you are interested in other features please don’t hesitate to contact us.

You can visit the site, that was build on top of dojango (wohooo) at http://dojofoundation.org.

It was great to work together with the people of SitePen and I hope there will be more things in the future where we can join our forces.

First I’ll explain how dojo uses namespaces and how you can preload files with it and afterwards i’ll describe how you setup a django project using dojango and adding your own django app with its own dojo namespace.

Explaining the Dojo Loader

It is important to understand, how dojo loads files and how dojo utilizes their namespace structure before creating your own one.

At the beginning there is the dojo base system, that is loaded via a script tag in your page and which enables the dojo namespace on your page:

As you maybe already know, dojo comes with the two other namespaces dijit (layout and form widgets) and dojox (extensions for dojo and experimental stuff) and an addtional namespace called util, where the test-runner of dojo is located (concerning js namespace and dojo loadable module). You can see that stated in the 4 directories dojo delivers and where each directory represents a namespace:

Beyond loading the dojo base system you are then able for example to load the richtext editor widget by using the dojo.require function, that belongs to the dojo base system. By calling this function dojo resolves the namespace dijit relative to the parent directory (../) where the file dojo/dojo.js resides. The following dojo.require call would load the file dijit/Editor.js and all dependant classes and functions used by the richtext editor. If the dijit.Editor already was loaded it wouldn’t refetch the JavaScript files:

You can change the namespace resolving behavior by using the dojo.registerModulePath function. If you do that in front of the dojo.require call, the dojo module loader will deliver requested files of that defined namespace from the given path:

Besides that we also need to differentiate between a local and a xd (crossomdain) remote version to understand the module loading of dojo.

For a local loaded version (see Add Dojo Source Guide) you just need to place your new dojo namespace directory (suggesting “myapp”) next to the dojo, dijit and dojox folder and you then can load your dojo javascript module myapp/MyModules.js with dojo.require(“myapp.MyModule”). Alternatively you can place your dojo module “myapp” somewhere else and register that path with dojo.registerModulePath.

Assuming you load dojo from an external CDN like AOL or Google and you also want to create your own local dojo namespace, you have to consider two things. One is that you have to set the parameter baseUrl in your djConfig to “/” when loading the dojo base system:

The other thing is that you have to register your module path absolute:

Now you’ve understood the dojo module loader, you are ready doing the next step transferring your new knowledge to a concrete django application.

Creating the reusable django app “myapp”

We assume, that you’ve already installed dojango within one of your projects. If not, you first have to follow the instructions in the getting started guide of dojango.

First you have to create your own reusable app within your django project and add a directory, where you place your javascript and css files:

Within the media-directory you now can place the directory that serves as your new base dojo namespace. Our recommendation is to name the namespace and the directory like your django application (in this case: myapp):

You also need to enable django to deliver the static files with your development webserver. For that you create a myapp/urls.py and add the media path to it:

and include the app specific urls.py in your project’s urls.py, so all media-files are available below the url /myapp/media:

And also myapp must be enabled within your django project in settings.py (as with dojango):

Defining a Dojo Namespace with Dojango

We propose a basic structure for your new namespace. You should create a file called myapp.js, where you can set all modules that should be loaded if your namespace is required and a file called _base.js that contains simple functions that you want to call directly below your namespace: something like myapp.showInfo(). This proposal was adapted from the dijit namespace:

And here is the content of our myapp.js. As stated above we need two paths to our module, an absolute and a relative path. We’ve added an extra function called dojango.setModulePath, that is accepting an absolute and a relative path, so dojo source switching is working properly within dojango (Note: the function dojango.setModulePath will soon just need an absolute path, because we can calculate the relative path. But that change will be backwards compatible, so you don’t have to worry about it now!):

And as told above we use the _base.js for placing our main functions, that we use throughout in our app, of our namespace:

Using your Dojo Namespace within a Django View

Now it is time to see everything in action. For a usage example we create a new url, a view and a template.

First mapping the url within myapp/urls.py:

Then adding a new view to myapp/views.py:

Lastly we create the template-directory:

And place our template myapp/templates/myapp/example.html there:

Start you django server via python manage.py runserver and test the example view here:

http://localhost:8000/myapp/example/

Yes. That really was a long blog article! But I hope, that this info will help you to build a nice ajaxified reusable application for django that is using dojo (and of coure dojango :-)).

JSON communication with the server
There are enough use cases (and they are becoming more) when you want to get data from the server and the most common data format nowadays for that is JSON, for various good reasons.
Let’s construct a simple form who’s data we want to submit to the server and know if it all went ok or not. For now we just print the submitted data on the django console (from where you started the local dev server) and we let the user know about the submission with the small text “Submitted” beside the submit button.
So let’s get started with the JavaScript side. Dojango luckily provides us with the basic infrastructure, so let’s create a template that extends dojango/base.html (it is available since the settings.py includes the app “dojango”, see here for instructions), that provides us with everything we need to have dojo running even the doctype of the document and HTML headers, just in short a valid HTML file, we only have to worry about our code.
So let’s build the simple.html file in the templates folder of our django app (I called my app “core”).

As you can see we are overriding a couple of blocks, that are defined in the dojango/base.html. The first one (line 3) is just for setting the page title, the second one (line 5) is for putting our JavaScript code inside html-head. And “dojango_content” (line 21) is finally the content of the body node.
We also have to wire up the template to render when we access http://localhost:8000/simple/ and the AJAX method, that we submit the data to, like so in the urls.py:

We just added the two last lines that map our URLs (line 6 and 7) to the view functions.
Our views.py just needs to implement these two functions, like this.

The function “simple” (line 4) uses the standard django way to render a view and return the content to the client. It finds the template simple.html in the app’s template path.
The function “simple_ajax_set” (line 8) will receive our form data and (for now) only print them. You can see the first speciality here, it uses the decorator “json_response” that we imported from dojango.decorators. This decorator takes care of returning proper JSON data, all the data you stuff in there are returned to the client JSON encoded, it basically is json_encode as described here. If you have AJAX calls and want to return JSON data, this is the easiest way to do it and it comes with dojango. It is a special (though very simple) implementation that has not made it’s way into the django core because it is really just AJAX-focused, while the django serializer is django model focused. Additionally this implementation solves a couple of problems and adds some features that are very useful when working with AJAX data, for more explainations see this article.

Handle the return
Now we can submit the form and see that the data got submitted. We don’t know yet if the data had been successfully handled on the server. So let’s add proper error handling.

If you looked into the return data (i.e. via FireBug) you might have seen that

was returned. But until now this was passed into the load function (line 8) as a string, but we want them as JSON. So we have to tell the xhrPost() call to handle it as JSON (line 4). Now we can also evaluate the success value easily as shown in line 9. If the server returns

with the value

we know something went wrong on the server. Let’s implement on the server that the surname has to have at least three characters. In the case of an error the server returns the additional property “error” which we then show to the user (line 12) to inform him about the error.
The function in line 15 handles all kind of connection and/or submission errors that may occur in a lower level. Make sure to not leave your users in the dark about this.
Let’s look at the server code for that:

We extended the function a little bit to do some simple error checking. You can see that we add the key “error” to the ret dict, which is then passed to the client if the surname was shorter than three characters. The JSON string returned in this case is

.
Note that we didn’t explicitly set the value for

to

, the decorator

handles that for us. If no exception is thrown it assumes that the function went ok and it can return

. This comes in very handy, especially when you just have simple one task AJAX functions that i.e. just delete an item, you don’t have to return explicitly that the deletion went well,

does that for you if you throw no exception. We just made it the default behavior since it was right for most of our use cases.

A quick summary of the main features of dojango:

• a reusable django app that provides dojo
• easy dojo setup inside django
• build an optimized dojo
• some helper functions, i.e. JSON conversion
• switch easily between different dojo versions.

The main purpose of dojango is to help you using dojo within your django projects. Currently it delivers the main infrastructure to easily switch between several dojo versions and includes several functions that helps developing rich internet applications. Now we are able to chain dojo and django on a solid basis and we work at porting the actual django form widgets to use dojo widgets.

We would be happy, if a lot of people would test the current version and tell us about bugs, strange behaviors, misunderstandings, … Also we are open for everyone who would like to help out extending dojango. In coincidence Roberto Saccon (big thanks!) already testet dojango with google app engine and it worked at first go.