Django Basics : Part -1

django

INTRODUCTION

So, what is Django? It is a very popular web framework based on Python. I love it because it is fast and because it is Python. I like it because it is simple, easy to learn and has all the things necessary to build a web application with a full fledged 3 tier architecture ready. Its ORM or object relational mapping system is world class and so is its template system. As of today, the latest version of Django is 1.9.2.

The intention of this tutorial is to help you understand its components and help you build a basic Django website with a database and views, available to serve pages using is temporary server(Apache etc. are USEFUL in production). Django is huge and so is its documentation. So, I won’t delve beyond the point where you can tell the differences between a view, template, model and static pages in this PART 1. Oh wait! I forgot to inform you that this tutorial on Django is divided into multiple Parts and I will keep posting them one by one based on my time as I sometimes really get busy with my work. But you see, I love writing my blog posts and hence, I WILL find out some time to help my readers create awesome web apps!!!!

Before I proceed, I would like to inspire my readers by letting them know who are the players using Django today :

  • Instagram
  • Pinterest
  • Mozilla
  • The Washington Post
  • Bitbucket
  • Speir.tv
  • More…

BASIC COMPONENTS of a DJANGO APP

A Django app consists mainly of the following components :

  • Models
  • Views
  • Templates
  • URL Dispatcher
  • Database

the-django-web-application-framework-2-12-728Let me introduce every component briefly:

MODEL

It is the Model equivalent from the MVC Framework. For example, if your web application is about an online Music Portal having details of artists and their albums, there could be two probable models, namely, Artist and Album. Each model will have its own attributes. For example, Artist will have artist_id, name, age, twitter_id etc. as its attributes whereas Album will have album_id, name, date_of_release and artist_id as its attributes where artist_id would be a foreign key corresponding to the artist to whom the album is attributed to. It is simple stuff for you if you have prior object oriented programming experience. There’s a lot more about models which will be properly explained in a future tutorial, probably with a running example.

As a side note, as soon as you create a model a database entry corresponding to the model DOES NOT get created. But, once you ‘migrate’ the changes, the Database is updated with the new model data. This and a lot more will be explained later.

VIEW

The funny part is that this is NOT actually the equivalent of the View in the MVC architecture but more like the Controller equivalent of the MVC architecture. Confused? Don’t be. It is simple. Just get used to the idea of the View in Django being the main logic controlling component that handles the requests based on certain URL patterns and generates output accordingly. In a very simple tone, every view responds to a certain request by presenting a template in some form or the other. When I say a template…..

TEMPLATE

…it basically means the front end component in Django. It is filled or not filled with ‘context’ data that is , when sent, sent from the view that led the application to the template.  Generally, html files but sometimes could be anything else, like JSON, XML etc. Content type and other response variables are sent from the view.

In layman terms :

  1. Request_URL leads to View A
  2. View A processes Context_Data + Template
  3. Template presented with Context_Data

DATABASE

The actual database that generally the user or developer need not see. But can be easily seen. PostgreSQL, SQLite, MySQL…could be anything.

URL DISPATCHER

A file, urls.py contains all the URL mappings as what URL pattern leads to what view.

IMPORTANT METADATA

It is very important to note that a Django Project may contain 1 or more Django apps where each app comprises the aforementioned components. Now, I would like to explain briefly the directory structure of a Django project.

screen-shot-2009-09-14-at-2-08-32-pm

Here, project.domain.com is our Django project which has a testapp app inside corresponding to the parent project. As you can see,testapp has a file called settings.py which has all the settings for the entire project and there is ONLY 1 settings.py. The public directory is for publicly accessible, mostly static, files.

Note : Every directory in an app needs to have a file __init__.py to tell Django that it is a django directory.

To Be Continued…

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s