In the previous installment of this series, I explained that a Django site is normally organised into a 'project' which contains 'applications'.

We started a new Django 'project' (i.e. a website). This was a directory with a few files in. The most interesting were settings.py, the project's settings, and urls.py which maps URLs to functions.

Now we will do the other part and start an 'application', this could be any dynamic feature of your site. For this series, we will be unoriginal and create a simple blog.

From within your project directory, type the following:

python manage.py startapp blog

You now have a directory called 'blog'. This contains three files: __init__.py , models.py and views.py.

__init__.py is another stub, to make Python see the directory as a module, just ignore it.

This leaves two files that we will need to edit.

models.py will describe your data structures and provide access to them.

views.py will contain the core logic of the web application. This is an over- simplification, but accept it for a minute or two.

How Django Works

Now we have seen most of the parts, it would make things easier to understand if I attempt to explain how they fit together using a quick and dirty diagram, as you may expect, I have simplified things to prevent detail overload. Go around the diagram anti-clockwise.

At the top of the picture is the web-browser, i.e. what you are using now to read this post. The user clicks a link to visit a Django powered webpage and so the browser makes a request. The web server eventually hands over to urls.py which then matches the requested URL with a function in views.py that will handle the request.

views.py can then run whatever logic (i.e. Python code) you want, including reading or writing stuff to the database using the classes imported from models.py.

When this is done, views.py will then send the relevant data back, this "response object" will be combined with the relevant HTML-based templates to form the response, which is then displayed in the user's browser as a web page.

The user can then click a new link and go around the cycle again.

So in the example of a blog, The user clicks on a link to see an entry. The webserver hands on the URL of the link to urls.py, which then calls an entry function in views.py.

All of the entries are stored in the database, which is accessed via models.py. views.py will take the entry's title and body, which will be combined with a template and then sent back to the user.

Logic everywhere

So hopefully you can see now that saying that views.py contains the 'logic' was a gross simplification, as there is 'logic' in lots of places:

• urls.py maps the URL to functions
• models.py provides data specific logic
• Templates provide the presentation, including simple and limited presentation logic.
• views.py sorts out the response and performs anything else that needs to happen on the server-side before that.

Sometimes there won't be very much for views.py to do at all; in that case the relevant function in views.py (commonly called a 'view') will be just two or three lines.

In a more complicated view, you might import many other modules, such as those provided by the Python standard library or via the Python cheeseshop. This kind of view can get quite long if you want, or you can split off some of this logic into seperate modules.

That is enough for today. Explaining this simply is a bit hard, as too many simplifications can result in unwittingly misleading you. Hopefully I have not made too many of those in my explanation, if I have then you know the drill, please leave a comment below and I can clean it up.

Discuss this post - Leave a comment