Why Django?

…and whatever else I feel like writing about.

Ajax, Dajaxice, and Taconite

Before I dive into these three topics, a word about the Category: Simple Is as Simple Does.  Part of the whole reason I switched over to Django after programmer for years in languages as PHP, Java, and C# was because of how simple I found the Django framework to be. The more simple and the more organized you can keep your projects, the faster they will get done.

The last time I posted, I wrote about Virtualenv and Virtualenvwrapper.  I like using these two tools because they make life very simple when it comes to keeping track of your dependencies, not only during development, but also when it comes time to deploy.

Now, back to Ajax!  I’m going to make the assumption that you already know what Ajax is and why it is so popular.  We want to add content to a page, or modify content on a page, but we do not want to force a refresh of the entire screen.  Since I am building a web app that will require a lot of interaction from the user, and my pages will be changing quite a bit, depending on what the user clicks on, I knew that I would be writing a lot of Ajax in my code.  But I wanted something really simple.

I started out using straight jQuery Ajax.  I downloaded a very simple sample project posted on an article created by Nizam Sayeed.  You can download the ajax_user_list.zip file from that site, and see how simple it is.

But I was looking for something even more simple.  I ran into Dajaxice.  It took me a while to figure out how to get it installed.  I think it was just bad timing.  Once Jorge Bastida posted his updated version with its installer, and once I switched over to using Virtualenv, it installed great.  But, the examples of how to use Dajaxice were very short and few.

I didn’t get very deep into using Dajaxice, because while researching Dajaxice, I discovered a better tool: Taconite!  Taconite is a jQuery plugin that not only simplifies your Ajax calls, but it allows you to separate your Ajax calls from the client side, and organize these actions and modifications from the server side.   There is a great deal of information and examples of how to use Taconite out on Malsup’s Taconite site.  If there is a downside to using Taconite, it is that it is so simple, that it may be hard for some to grasp, at first.  At least, this was my problem.

The examples on Malsup’s site were mostly PHP examples.  I had trouble finding many examples of Django implementations.  Peter Rowell posted a simple utility class for Taconite on his Techbuddy site.  With a little effort, and some coaching from Django programmers who have used Taconite, I was finally able to get it working in my project.  And, Yes! It will simplify my life a great deal!


Virtualenv and Virtualenvwrapper

Virtualenv and virtualenvwrapper are two django toolkits that I wish that I would have learned when I first started using Django. Virtualenv is basically a virtual environment, that is very easy to set up. It allows you to maintain multiple projects that have different dependencies.
Since the articles about these toolkits are very well-written, and self-explanatory, I will simply refer you to those documents.
However, I do want to give you one word of advice, that I didn’t learn until after I spent several hours studying about these toolkits:
That is, you should really install virtualenvwrapper right after you install virtualenv–before you follow the instructions to call ‘virtualenv’ to create your virtual environment and ‘source bin/activate’ to activate your virtual environment. Then, rather than calling ‘virtualenv’ to create a new virtual environment, I would call ‘mkvirtualenv’. BE SURE TO CALL ‘mkvirtualenv’ with the ‘–no-site-packages’ option. If you do these two things in that order, you will not have to worry at all about modifying your PATH or your PYTHONPATH environment variables. This will all happen automatically.

Okay, so if you are new to Django, all of that probably went right over your head. That’s okay. It will all make sense after you go through these excellent articles. And it will make life a breeze for you as you add dependencies to your project, and especially when you are getting ready to deploy.


To make things even more simple, since some of the articles above on virtualenv might have been written before virtualenvwrapper was available, I will give you the order that I installed and set these up in my environment. I am running on a Ubuntu 10 server, and I use Eclipse for my development environment.
I create all of my work projects in my ‘data’ directory right under root. I create a ‘envs’ directory inside ‘/data’, which is where all of my environment directories will be created. Inside each environment, I create a ‘projects’ directory where each project that will use that same environment will be created. You can organize your environment however you like. This is just what works for me.
Of course, you can skip the first command if you already have the setup tools (easy_install).

sudo apt-get install python-setuptools
sudo easy_install virtualenv
sudo easy_install virtualenvwrapper
export WORKON_HOME=/data/envs
mkdir -p $WORKON_HOME
mkvirtualenv --no-site-packages env1

Notice that ‘mkvirtualenv’ automatically activates that environment. To switch to a different environment, just call:
workon env2
where ‘env2’ is the name of the other environment.

Now, you can install whatever packages you will need in your new environment. For example:
easy_install django
easy_install django-dajaxice

At any point, you can call:
This will give you a list of packages installed in your virtual environment.
After I create my virtual environment and install whatever packages I need, I then call:
mkdir projects
cd projects
django-admin.py startproject myapp

And when you are ready to startup your app:
python manage.py runserver

Before using virtualenv, I noticed that some packages would not get installed into my site-packages directory.
Thus, my PYTHONPATH did not include these packages, and I saw all kinds of errors trying to use these libraries in my project.
If you are using Eclipse, you will need to create a new workspace that points to the projects directory in your new virtual environment.
Also, inside Eclipse, go to Window -> Preferences. Expand ‘Pydev’ and select ‘Interpreter – Python’. Click ‘New…’ and browse to your new python path.
For me, this was: ‘/data/envs/env1/bin/python’. Your list of libraries in your PYTHONPATH environment variable should now be listed under libraries. Click ‘OK’.
One more note. To deactivate, or exit an environment, just type:
at the command prompt. I got this confused with:
source bin/activate
which now gets called automatically when you create the environment using ‘mkvirtualenv’, or when you switch to an environment using:
workon env2
If you have any further questions, the quickest way to get an answer (AFTER reading through the documentation, of course!) is by searching in the django users forum and submitting new questions if you do not find your answer.


Why Django?

I guess the first question for some, would be ‘What is Django?’

Django is an open source web application framework that uses the Python programming language.  It follows the MVC (model-viewer-controller) architect.

Before I answer the main question that is the purpose of this blog, I would like to tell a little about myself.

I am L. Jay Adams.  I have been a programmer in the professional world since November of 1993.  I started out programming in C and AppleScript on a Macintosh, as well as interfacing with Sybase databases on Sun Solaris.  Through the years, I learned many other programming languages.  I took a Java class the first year the local University had a Java class.  I continued with C, C++, VisualBasic, Perl, C# (.Net), PHP, ActionScript, Flash, Flex, JavaScript, CSS.  Eventually, I decided that, although I do enjoy learning, for my career’s sake, I should settle on one language, so I would not get left behind with all of the fast-emerging technology.  A couple of years after I settled on .Net, I lost my job.  I took a temporary job that only lasted a few weeks, but I picked up another platform that I had never heard of before: Django.

It didn’t take me long to get used to Django.  In my opinion, it was the easiest web application platform I had ever used.  The Python language comes fairly easy, especially if you have ever used PHP.

I think part of what really makes Django seem so easy, is that you don’t have to spend hardly any time worrying about the database communication layer.  You don’t even have to write queries.  Not that I mind writing queries.  I have been writing database queries, as well as code that executes the queries, in multiple languages for my entire career.  But, for the first time, I found a platform on which you don’t have to spend the biggest chunk of your time messing around with the database communication layer.  You simply create your model in a file typically named ‘model.py’, then run a python command with a ‘syncdb’ option, and your database is created automatically for you.  You can also create a ‘fixtures.py’ file that has all of your initial database contents.  This way, as you add fields and classes to your models, you can simply delete your old database, rerun the ‘syncdb’ script, and your new database will get created, and populated.

Other languages may have this same concept, but I have never seen it done so easily, and with out having to write a lot of queries.

I will talk more about the database communication layer at another time–or you can read more about it in some of the books on Django.

Another reason I feel Django is so easy is because it is the first MVC platform that truly makes the MVC model look like a piece of cake.  As I just explained, the models are easy to create.

One of my hurdles was that I always understood the viewer to be the front-end visible to the user.  So, in my mind, the templates represented the viewer–and maybe it does.  (Feel free to comment if you are a django user.)  Django templates are very simple to understand, create, edit, and render.  You typically create a  urls.py file that lists your URLs and tells the python interpreter which functions should get called for each URL.  These functions are then defined in the views.py.  These functions can access data from the database, make calls to your controller or business logic. Then they use your templates to render your pages.

I don’t know why Django seems so easy for me.  Maybe I was surrounded by really smart programmers.  But, I have been surrounded by extremely smart programmers my entire career.  I just think that Django is just that much easier to learn and use–at least for building web applications.

Django was originally developed by web developers in Lawrence, Kansas, primarily for building pages for a newspaper.  They needed a way to build pages and applications as fast as possible without having to spend time managing a bunch of database queries.

I’ll continue to write more here later.  But if you want to dive in and see for yourself, I recommend starting on the Django documentation site.