Search This Blog

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.

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.

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

Comments

Post a Comment

Popular posts from this blog

It was not that long, since I experienced a problem while trying to upload a file using an ajax trapped form. I thought, it must be me doing something wrong. I was using web2py to embed another page into a page via ajax. That is better known to web2py folk as LOADing a component.

It's just happened that one of such component contains a file upload form. It was my first time using LOAD function provided by web2py. Basically it make use ofjQuery to load the page via ajax into a target div and traps input of any form in that page, so that page doesn't reload. Oh, I forgot to say that web2py is bundled with jQuery.

It's always boring and tedious to understand a problem without experiencing it. So, Let's play with an example, (PS: I"m using web2py a full stack python framework, but you can use any language at server side and this problem will be there because, it's a problem with ajax)

We all are hearing the buzz about Rich Internet Applications (RIA) about a year or so. But, what the heck is that beast? You may ask. For the user's perspective, it's the desktop like experience delivered over web. Yes, you feel like you are using a real desktop application (well, at least sort of). The richness of desktop controls is transferred to web.

How RIA is build? Arise another question. These all started with that amazing kid called AJAX (Asynchronous JavaScript And XML). Then more and more tools become available, like Java FX, Adobe Air, Adobe Flex (and Adobe Flash), Microsoft Silverlight. But these tools, though it gives rapid and organized web application development, required some kind of plug-ins to be installed on your browser. There is the importance of AJAX based RIAs, because JavaScript is enabled in almost all browsers in use today.

However, It's not a fool proof solution, because there are people who switch off JavaScript for some reason, like me ;-). Bu…