Tips to a new django developer(blog.dpeepul.com)
blog.dpeepul.com
Tips to a new django developer
http://blog.dpeepul.com/2009/08/31/top-10-tips-to-a-new-django-developer/
16 comments
You're right. Another handy way to do this is to keep debug as False and use middleware to show the debug error if you're logged in as an admin or from an IP that matches in INTERNAL_IPS:
http://ericholscher.com/blog/2008/nov/15/debugging-django-pr...
Sort of the best of both worlds.
http://ericholscher.com/blog/2008/nov/15/debugging-django-pr...
Sort of the best of both worlds.
Please, for the love of conciseness, never assign a boolean based on an if statement.
An odd thing thing about this piece of advice is that it contradicts a lot of the previous advice which is 'don't hardcode stuff'
This pattern is questionable for another reason - basing the app's configuration on some other, largely unrelated configuration (in this case, that of the network) can lead to elusive and annoying bugs. Configuration problems are much easier to debug when an application is told what its configuration is rather than trying to magically divine it from its environment.
I generally agree with all of the tips except for using Pinax. I like the idea of Pinax, and I think it makes a great sample app if you want to see what good Django code looks like. It's maintained by top notch developers and showcases a lot of excellent reusable apps and good Django design patterns, but when it comes down to customizing a Pinax app to create something you want, it's a nightmare. The internal apps are too tightly coupled, and it takes longer to take out all the stuff you don't want than to just roll your own apps from scratch.
More pinax discussion here: http://news.ycombinator.com/item?id=764566
More pinax discussion here: http://news.ycombinator.com/item?id=764566
Very valid point.One thing which i would like to mention is the idea is really powerfull and pinaxproject has just started.I think it really takes quite an amount of time for the project to get maturity.
I think still we need to put more thought on the below questions...........
1.How can we easily plug/unplug the django apps?
2.How easily can we customize a single app effectively?
1.How can we easily plug/unplug the django apps?
2.How easily can we customize a single app effectively?
I'd like to add one here (and as a 'new' django developer myself take it with a grain of salt), use the save method in your subclasses of 'models.Model' to do things like computed fields and other trickery to keep your database consistent.
Otherwise you'll end up doing this in multiple places throughout your views.
If your database supports it triggers, stored procedures and functions are probably a better way of achieving most of these things.
By putting a save method in your subclass you get access to the record about to be created or updated, you can use this to lift the id field out and do tricks with it just after insertion in to the database, or you can store the value of a field that can not be easily computed during data retrieval.
I use this in an application where each page appears as a leaf in a tree to update the path to the node based on the parent node and its path.
Otherwise you'll end up doing this in multiple places throughout your views.
If your database supports it triggers, stored procedures and functions are probably a better way of achieving most of these things.
By putting a save method in your subclass you get access to the record about to be created or updated, you can use this to lift the id field out and do tricks with it just after insertion in to the database, or you can store the value of a field that can not be easily computed during data retrieval.
I use this in an application where each page appears as a leaf in a tree to update the path to the node based on the parent node and its path.
I think that the preferable way of doing this is using signals.
Personally, I intentionally hardcode my URLs.
This forces me to think about my URL design up front. Then, if I decided I want to change URLs later, I've got plenty of time to come to my senses and stop. Public URLs shouldn't change, so this can only ever be a problem during development where a quick `vcs diff` renders the problem practically moot.
This forces me to think about my URL design up front. Then, if I decided I want to change URLs later, I've got plenty of time to come to my senses and stop. Public URLs shouldn't change, so this can only ever be a problem during development where a quick `vcs diff` renders the problem practically moot.
I try to make reusable applications of most everything I "know" that I'll be using more than once or twice. Permalinks and named URLs are pretty handy when you do not use the same URLs across different projects.
(EDIT: Added "Permalinks and" before "named URLs".)
(EDIT: Added "Permalinks and" before "named URLs".)
to
It's better practice to whitelist one box than to enable DEBUG on all computers but the production server - what if you deploy to another machine without thinking?