A Basic Django Workflow

Bruce Lee understands flow like no other

Having done about 5 – 6 mini apps in Django now, I’m beginning to get into a sort of rhythm. One of the questions I had early on was “What is a good Django workflow”. The answers were good but kind of high level for my liking. Also, given that I’m not trained in the art of Agile Development, terms like actors, continuous integration and the like mean very little to me. Having said that however, I do understand its importance especially in the context of  Lean Startupbut this is not the time for me to get involved with more jargon and complexity at this stage of my learning.

So this is my current hands-on workflow for a new Django app:

Django Workflow

  1. Create a new project and a new app called mainapp
  2. Edit settings.py. Fix the following:
    1. Database settings
    2. Installed apps
    3. Media and media admin paths
    4. Most recently, to add CSS and JS paths
  3. Edit urls.py in the project folder and
    1. Uncomment the admin paths
    2. Include mainapp.urls.py
  4. Create a new urls.py in the mainapp folder
    1. Create a path that display a view called home
  5. Create a new templates folder
  6. Create a base.html file in the templates folder
    1. Create a place-holder variable within base.html
  7. Edit the views.py file. Create a new view called home and return ‘hello world’ using the base.html template and a place-holder variable
  8. Create a media folder the project folder (1 level up from the mainapp folder)
  9. Edit the models.py file
  10. Run syncdb
  11. At this point, you should be able to access both your admin page and your homepage that outputs ‘hello world’ by running the development server
I think this process is applicable to any new Django project and serves to get the ‘paperwork’ out of the way so you can start getting on with the actual coding within your views.py file. If you have any suggestions or if I’ve missed something out (I had to write this post twice x_x), do leave them in the comments.
Lessons Learnt
  1. Django’s strength is also it’s weakness. It’s easy to get a new project going but changing the database structure is a pain. You can’t add new columns to an existing table in your models.py file and expect syncdb to update your database schema. This is a recgonized problem and tools such as South have been created to address this. I haven’t tried using it yet and I really ought to.
  2. I need to start looking at other Django projects to see how others layout their apps. Right now, I’m working on a reporting app for Insync (gdocs sync) and my views.py is very big. I’m not even sure whether others consider it to be big and that what I have is the norm. So when is a good time to split it into another app within the project is a question that is on my mind. So if you’re a Django Jedi Master looking to deposit some goodwill in my goodwill bank because today you, tomorrow me, do let me know 🙂
  3. Think I need to start reading on the forms feature in Django. It takes care of trivial situations like this question I had — remembering a radio button selection.
  4. Also need to start reading up on Django unit testing at some point.

17 thoughts on “A Basic Django Workflow

  1. Thanks for this – launching my first-ever Django site in a few weeks and this is pretty much how my development process has evolved along the way. Although like you, I’d be interested to look at someone else’s code to see their methods! I’m a convert from PHP frameworks so a lot of it is new, but very exciting when I come across the new techniques (simplicity of ManyToMany, for example). Thanks!

  2. You should really give South a try sooner than later, you’ll kick yourself for wasting time making database changes manually. I put it off for a while, and had a few false starts, but eventually I figured it out and I’ve been a huge convert ever since. South has a few interesting gotchas that aren’t really gotchas if you really read through the docs and understand the the workflow for using South itself, but once you “get” that workflow, it makes things really nice. Shoot me a line if you want me to give you my 60 second (ok, more like 5 minute) South workflow rundown based on my own experience with using it. I wish someone had given me a good talking to back when I was going back and forth trying to figure it out.

    • I am in the shoes you were before. I have been putting off looking into South for a long time and doing all schema changes manually. The reasons for putting it are that I have many existing models and it seems not trivial to learn and not get anything wrong (I can’t have things breaking on the deployment server because I misused the tool). I would really appreciate a comprehensive rundown.

    • I’ll probably take you up on this as soon as I get my hands dirty first (don’t want to waste your time asking dumb questions). Thanks for the offer!

  3. Point 2: you can make a views module, instead of one large views.py you have a views/__init__.py that imports the views from files in the same directory. It keeps things organized if you have many views that need to be there because they belong together.

    • Do you have an example of this? Sorry, I need to look at things directly for it to make sense to me. Still very much a newbie in the world of Python too 🙂

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