Posted: July 8, 2009 - contribution by ron scheckelhoff -- rscheckelhoff- at- fourcalorieservers -dot-com

A first look at a web development frameworks made by the people at www.DjangoProject.com¹ (version 1.0.2)



I have heard developers talking about the Django Project (not affiliated with this site), but have never taken the initiative to download, install, and use their framework for Web development.

Until now.

We obtained a copy of the latest version, in order to review it. We quickly put it through it's paces, and found it to be a workable product.

The framework is named in honor of the famous Jazz guitarist, and I am unsure of the logical connection. Perhaps software is like music? Certainly the web is.

Personally, I think that the name was chosen due to the happy flavor it suggests - like a lime and your favorite drink.

My first impression is that the framework makes a better lime than a lemon. (See test results)

Well, the reader may be asking, "is it lime or is it lemon?"


The frameworks is used by some big name companies (a blurb on the main site mentions the Washington Post as a major user of the frameworks). So, I was very interested in seeing for myself what it was all about. After a bit of a rough start, the answer, as this author perceives it, is lime. Accordingly, the colors on the main Django site are mouth-watering lime colors. Every time that I visit their site I think of the song "... put a lime in de coconut and shake it all up ... "


I prefer to evaluate products by making an analysis in each of several passes, and I have a reason for doing so.

• The first pass is quick, and so in many ways mimics the effort of a person whose needs indicate a
  requirement for fast ramp-up, low learning curve, and respectable results.
  
  
• The second pass is more in-depth, and is compared to the results of the first pass, to determine how
  much slipped through the cracks, or was misunderstood, in the first pass.

In fact, this is the way many persons learn and study, and in any case, this procedure is the norm even for people who don't consciously consider what they are doing. The difference is, for me, the conscious notation of what was learned on each pass.

At the start, a minor version conflagration was caused by my use of my favorite operating system (FreeBSD), and the dated port that I found in the binary package repository (version .97 versus the current 1.0.2). My suggestions for others who might want to do what I am doing here are two-fold:

• Use FreeBSD (why would anyone consider anything else)?
  
  
• Download the latest gzipped-tarball for the framework, extract
  it into a convenient directory, and run the setup.py script to install it.

I guess a little personal preference bordering on bigotry shows through my suggestion (#1). To be fair, I use an older version of Debian on occasion, and it's mostly as good as FreeBSD in most respects. What it really boils down to (get ready for soapbox moment), is the perspective of the user/developer, relative to licensing concerns.

The FreeBSD/Xorg/MIT type of licenses appeal to people who like the idea of giving open source software away (for free), but do not want to be compelled (forced) to give open source software away for free (The GPL camp).


The Unix/Linux realm has split on this issue, and each group has gathered around themselves a core set of applications, mostly conforming to the license type favored by the group.

For example, folks who prefer the BSD-like licenses, (like me), tend to use the likes of FreeBSD for an operating system, PostgreSQL for a database, Python for a scripting language, and OpenSSL for secure socket development (all under BSD-like licenses). As it happens, Django carries a BSD-like license, which is sensible given that it rides on top of Python.

Now, back to the task at hand:


After I completed the installation of the latest version of the framework (version 1.0.2), I allotted some time to run through the excellent tutorial to be found at:


http://docs.djangoproject.com/en/dev/intro/tutorial01/

My suggestion to those readers who might like to educate themselves via the framework tutorial is to slow down and take a deep breath. It is advice that will save some backstepping and confusion for any such readers. For skim-reader/headline-reader types such as myself, a common method is to skip the parts that we think are irrelevant, or window dressing. Don't skip anything in the tutorial, and be careful to execute every step as indicated. You'll be glad that you did.


The tutorial is laid out in such a way that it might tend to tickle us headline readers into skipping pieces and parts. Resist the temptation, and you'll do ok.

The framework under discussion is, as are most web frameworks, a means to divide form from function. In the pursuit of this goal, my observation is that Django does quite well.


Use is made of four major elements that define the system:

• Models
• Views
• Templates
• Director Urls

In the nomenclature of this particular web frameworks, a model is a Python class or classes that defines the data. Via some clever scripts, the data elements in this class are magically reflected back to a physical database in a process that does a pretty good job of abstracting the detail of same.


The views are represented by Python classes that provide target methods for the urls dispatched to them via a clever url pattern matching setup.

The templates are in the form of html markups, but with django-tags embedded in such a way that the tags represent the data provided by the applicable view which has, typically, provided such data in the form of a dictionary. The use of the special tags is described generally in documents that define the django template language.

In terms of the templates, this framework diverges from some other web frameworks that use XML. While this divergence may bring a frown from some in the field, it likely facilitates the use of the frameworks by web designers with less in-depth general programming experience.

So, to sum it up, we have magic data classes (called models) that sync up with a physical database that we can then pretty much forget about. We have a magic "front end" that takes the internet surfer's request, compares the associated url in a pattern matching scheme, and ships it off to the Python view class and method (referred to in some of the documentation as the "call back" method) that has been assigned to process such an url. The view class, being the glue between the abstracted database (model) and the surfers request, manages the logic that determines the fare to serve up to the surfer. As a final step, the view hands the logically prepared answer off to the template for display.

The tutorial instructs the tutoree to put the model classes into models.py, the view classes into views.py, the url matching patterns into urls.py, and the template into index.html.

To be continued ...

¹This site has absolutely no affiliation with and is not endorsed by the DjangoProject, (but we like their products). For information: http://www.djangoproject.com

FreeBSD, OpenSSL, PostgreSQL, and Python are all trademarks or tradenames held by their respective owners, and they have absolutely no affiliation with, and do not endorse this site in any way whatsoever.

---

Contact: (For this site, Fourcalorieservers.com) - Ron Scheckelhoff -- Email suggestions to: rscheckelhoff@fourcalorieservers.com ( )