Friday, 16 November 2012

Correct way to structure your Django 1.4 projects




PS: This post is written assuming you're familiar with Django and at-least have some basic experience trying to set-up a Django project (for learning or for some cool project).

Purpose: To show how to properly set-up your Django1.4 project after seeing other developers getting it wrong (seen it wrongly structured by my mentee, senior developers and junior developers at my firm.).


Django 1.3 Project structure: Initial structure followed by two apps added to the project.
Django 1.3 Project structure: Initial structure followed by two apps added to the project.

Refer above picture, where I shown a Django < 1.4 project structure. (I know, at least Django 1.2 & 1.3 follows this structure).

First tree view is of the initial structure that you will get by calling
$ django-admin startproject Proj
Take a note that manage.py, settings.py, urls.py are in the main folder.
Following  tree display is after creating two apps named app1 & app2. You'll do it as follows

$ ./manage.py startapp app1
$ ./manage.py startapp app2
Those apps are created in the same level as settings.py and manage.py

Django 1.4 Project structure: Initial structure followed by two apps added to the project. And at last a wrong structure that I've seen people adopting.
Django 1.4 Project structure: Initial structure followed by two apps added to the project. And at last a wrong structure that I've seen people adopting.


Now,  Django 1.4 changed this organization slightly. They now make settings.py & urls.py into a separate module (or app, whatever you like) along with added wsgi.py (which can be used as is for your Apache wsgi configuration, in most cases).

First tree view shows basic project structure after createproject.
~/Django1.4/bin/ $ django-admin.py createproject Proj
Note that an module called Proj is created with settings.py, urls.py and wsgi.py within Proj main folder.
You can rename main folder to anything you wanted (or keep it as it is).

Also note that manage.py is still kept at higher level (although Django1.4's manage.py is different from from the manage.py found in earlier Django releases).

Following tree display is obvious & correct way to structure your project. It's result after running startapp to create two applications app1 & app2.
~/Project/ $ ./manage.py startapp app1
~/Project/ $ ./manage.py startapp app2
Now app1, app2 and Proj modules will be available to each other if outer Proj folder is in python path.
Which will be in path, because manage.py is kept at outer Proj folder and runserver will do the necessary. Here every apps and django settings & routing are kept as separate modules. Isn't this great?
Well, I like it, it help me better organize things and was so obvious for me from start.


Just to show how others get it wrong by emulating previous project structuring - i.e.,your apps laying beside settings.py, urls.py and all (you know, we hate change :-/ ) -  see the last tree view.
Now, you have one app/module called Proj and your supposed to be apps app1 & app2 are - well correctly speaking - become sub-modules of your app called Proj.

Does it make sense now! Well then I succeeded, if not go and read from beginning, shoot me a mail, leave a comment or abuse (at least show some passion; eventhough I'm going to delete most of 'em anyway). 
Caution: Some might even try to copy manage.py into Proj module ;-)


Update:  An attempt to make it a screen cast happen just after posting this. I know there're lots of rough edges out there. Please bare with me and provide constructive feed-backs.
Find it at YouTube Or Vimeo

No comments:

Post a Comment

'