This is a post I’ve wanted to write for quite some time now, but there is so much say that I couldn’t get the time to write it all down. So I’ve decided to split the first impression on django topic into smaller articles, this being the first post from a longer django series.
I did some projects with python lately, and I like the language a lot, but none of them were involved building web pages. Some vim scripts, some automatization scripts or web crawlers. But not a single web script. Usually a company doesn’t switch easily from PHP to python, or to any other programming language, because of the costs involved (training, etc.), so it’s pretty hard to start a project on another framework. But here, things are a lot simpler. My job description consists of only 4 words: get the sh*t done. Aside from this, I have complete ownership of the projects I’m working on and I’m free to choose whatever technology I please.
Prerequisites
Installing django is a piece of cake. Just follow the instructions on their site and it works like a charm. If you’re using python 2.6, you will receive some warnings concerning the MySQLdb package which uses a deprecated package. Just ignore them, at least until you decide to upgrade to python 3.0 
Preparing the editor. I use vim for editing and I needed something to help me out with code completion, mainly because I’m lazy and don’t like to type long name, and second because I don’t know all the django’s components’ names by hard. I’ve tried pysmell, but it didn’t worked well, and, since it’s marked as experimental, I don’t think it is supposed to. So I’ve tried good ol’ ctags. This is my recommendation. To create a ctags index, simply type:
ctags -R -f ~/.vim/tags/python.ctags /usr/local/lib/python2.6/dist-packages
and in Vim
set tags+=$HOME/.vim/tags/python.ctags
And voila. It works. If you’re using python 2.5 use the appropriate path.
What I like about django
The admin. It rules, it’s simple to customise, it saves a lot of time. I love it. Back in the days, when I was using CakePHP, I’ve often wished that its scaffolding system did what django’s admin does now. I also love the authentication system. It is another well built component that saves a lot of time of routine work. The models – not having to write SQL statements by hand all the time gives me a hard-on. They also provide a logical separation between a single model object (which encapsulates a row in the table) and the statically declared information retrieval methods.
What I don’t like about django
The implementation of the MVC pattern is a little bit strange. They call it MVT (Model View Template), where “the view” is basically a controller’s action in the “traditional” MVC approach, and “the template” is what you’d expect to be the view.
It offers decent degree of logic separation, I don’t like it though that the action and method attributes are being set in the view…template. No one can tell me that where a form sends its data is presentation logic that should reside in a template.
The code generation scripts don’t always work in the way that you’d expect, for instance, if you change something in a model and run the
python manage.py sql myApp python manage.py syncdb
sequence and the table already exists, it won’t update it. And I hate the template system. Really do. I don’t get its purpose – I don’t get any templating system’s purpuse – and some things in it are really weird. I mean ifequal…hello? Not exactly syntactic sugar 
Conclusion
I like django, as it provides a quick and clean way of doing things. I will definitely use it in the future, possibly in my next project, so stay tuned for more django articles
You are right – form POST url’s aren’t presentation data.
But you can easily do:
and set your context accordingly.
With regard to templates. I agree with you to a certain degree – but the design decisions for Django templates have been fairly explicitly set out. They are intended for use by non-programmers and they are intended to discourage putting very much control flow in your presentation layer. You should be doing that work either in views or in template tags.
(second attempt at a comment as my html was stripped rather than encoded)
You are right – form POST url’s aren’t presentation data.
But you can easily do:
<form action="{{form_destination}}">and set your context accordingly.
With regard to templates. I agree with you to a certain degree – but the design decisions for Django templates have been fairly explicitly set out. They are intended for use by non-programmers and they are intended to discourage putting very much control flow in your presentation layer. You should be doing that work either in views or in template tags.
Yes, but it’s somewhat…not natural. I like Zend Framework’s way better. Don’t get me wrong, this is not a django bashing post, I’ll keep on using django from now on. I’m just highlighting its strong and weak points, as seen from my perspective.
PS: You can use <pre lang=”python”> to post code.