Monday, September 17, 2012

Django learning resources

Here is my list of Django learning resources, with brief explanations. I will use this both to help the community and as my personal reference, so I will try to keep this page updated. Since django is a web applications framework, and is written in python, I include resources for learning html5, css, javascript and python at the bottom.

Feel free to include other resources in the comments, and I will try to incorporate them.

Introductory Django resources

  • Django tutorial - This is the starting point, from django project. You also want to have the documentation site on your bookmarks :) 
  • The Django Book -  This is a much deeper intro, but covers version 0.96 (we're at 1.4 now); there is a review in process, to update it, but doesn't seem to have progressed much.
  •  Django by Example - This is another great resource, although slightly outdated (covers django 1.2). It develops a series of applications (todo list, blog, photo-sharing, forum and calendar).
  • Django Djourney -  I'm not a big fan of screencasts, but this series is pretty decent; The django project also keeps a list of screencasts.
  • Django for the impatient: Building a blog - This is a chapter from a django book, and a decent tutorial. I don't like that it's divided into 10 pages to make you click more, but ...

 Learning Python

Web development (html, css, javascript)

Thursday, September 13, 2012

including templates with variables

When designing code, we usually divide it into different functions or procedures, to simplify each piece of the code. Django's template system allows us to include a sub-template (there's nothing special about sub-templates, just how you thin about them).
For example, if we need display a table of items on a given page, rather than putting all the code we can write the code for the table in a different template page, and include it on the 'main' one, like this:
The template you include has access to all the variables in the 'main' template.
Once you start using include, you'd start thinking on how to pass values to the included templates so they behave somewhat different each way, much like you pass parameters to functions; you can just modify variables in the main template before including, since the sub-template has access to all those variables; however, django provides a nicer syntax.
You can use with, and specify a value for a new variable, that will exist only in the included template. For example:
As a real-life example, I am developing a program to deal with applications to our department; each application passes through different stages, and we need to display applications on each of those stages on each page, so I'm doing something like: Since there are only a few stages, I'm directly including for each one; if there were a large number, I'd probably put them in a dictionary, and iterate through them, but this saves me effort and ensures all tables look the same.

Tuesday, September 11, 2012

filter, spurious tuples and distinct

In django ORM, we can use filter to query our models; we can use double-underscores __ to follow relationships in our model, much like doing JOIN in SQL (in fact, it gets translated to join statements); however, the filter method introduces 'spurious tuples' when doing joins; this may or may not be a big deal, but it is good to know. Using distinct() will eliminate those extra tuples.

For example, imagine a simple model, consisting of a person class, which may have more than one email.
Then, if we add data for a person with one email, as follows: We can use the following code to get the people with a phone number in area '770' However, if the same person has TWO phones with that area code, we get TWO rows for the person. Basically, the filter function with the double underscores is doing something equivalent to the following SQL: where it should be doing: however, adding a call to distinct() will fix it; our query, adjusting for django's idiosyncrasy, is: and we can see the different results returned: And, for completeness, here's the code for adding the second phone number.

Thursday, September 6, 2012

Modifying choices in model forms

Django model forms are great, since they automatically create a form based on your model, saving you a lot of repetitive work; the bad part is that they create a basic form only.

For some applications, you may want to create your own fancy forms, but sometimes the basic model form is almost, but not quite what you want; in that case, you can directly modify the fields at run-time. A ModelForm has a field called fields, which is a dictionary, indexed by field names.

One situation I faced recently is that I wanted to limit the choices on a choice field; choice fields in django have a field called queryset, which you can replace with any queryset you want; I needed to limit the programs a user could access, based on which programs it was registered for; all I had to do was