Zed's "One Battery Review" of Django
zedshaw.com
zedshaw.com
- Always track the trunk, there's really no compelling reason not to. It's always extremely stable and full of new features you won't find in the tarball release.
- The ORM is good for simple things, but you may find yourself needing to write SQL if you're doing anything complicated. In reality this probably applies to any ORM, though. Even though people ignore it.
- Caching is built-in, effortless, and awesome.
- The template language is intentionally crippled in various ways to keep you from "doing too much" in them. Thankfully Django is modular enough to allow you to drop in a more powerful replacement if that's your thing.
- Django is basically retarded when it comes to multi-processing environments and should not be considered even remotely thread-safe. I mean it. Copious use of locks can usually keep transactions from walking all over each other, but your mileage may vary.
- If you want some piece of functionality or add-on or whatever, chances are somebody has already written it. Check djangoplugables.com and djangosnippets.org before wasting precious cycles.
What Zed does talk about are the conceptual things that make Django appear good on paper like reusable applications and he also likes Django's tip of the hat to Jazz. It's too bad he doesn't talk about stuff like the crazy ORM that Django has which seems to be the least Pythonic ORM out there, or whether or not Django handles string encodings well, caching, etc. That's the kind of detail I've enjoyed from Zed's previous reviews... err... rants. Hopefully we'll see some more substantial review in the future.
Now, lets quote Zed:
"Read it, and take it as a chance to discuss pseudo-macho speech online, and whether you really are only listening to perceived strength rather than reason."
I did some searching, and the highest ranked similar post I could find is this one which currently has 31 points:
http://news.ycombinator.com/item?id=404309
Want to bet this article gets more points? :)
(setq-default tab-width 4)
(setq-default indent-tabs-mode nil)
Also get ipython.el -- very handy. My .emacs is here for your reference: http://github.com/ki/my-dot-emacs/blob/master/dot-emacs.txtYou get to configure at least three things: how many things emacs enters when you press "tab", what those things are, and if you see a tab in a file how wide it should be.
It is better than the default vim python autoindentation behavior.
(1) The list thins out a lot after than. I agree with Zed that the apps-in-a-site structure is very cool.
...and ModelForms? http://docs.djangoproject.com/en/dev/topics/forms/modelforms...
In my experience, "simple CRUD" often gets complicated by permissions or other special cases, but generic views and modelforms are useful tools for hammering out a lot of the basics very very fast. Both of them allow for some degree of customization, but should be helpful in achieving what you want.
The reality doesn't really hit home for a few weeks. Django gives you all sorts of really cool stuff right out of the box that does nearly everything for you. The problem comes when you want to do something just that little bit different, and you find yourself unrolling every single piece of it one-by-one as you discover that these pieces don't fit your needs exactly.
I also found myself baffled by the terrible decision to make everything revolve around function calls rather than a Request and Response object. No matter what happens in your page flow, you still need to return a HttpRequest object at the end of the day. No more Response.Write();Response.End(); from any point. You need to have every bit of code capable of returning in a way that triggers the thing above it to return in a way to trigger the thing above it to return a HttpRequest object. Makes debugging a serious pain.
So yeah, if you're doing a simple CMS for a media site (which is what they wrote Django to do), it rocks the house. If you're trying to do any heavy lifting, it seems to fall apart pretty fast.
I don't think I'd use it again.
That said, it is still a full-stack framework, and it is definitely targeted at sites that mostly serve dynamic pages. Like all frameworks, it has its archetypal projects, and for Django it's blogs/CMS/online community apps. The further your project is from that archetype, the less useful the framework will be.
Sure, there were times when we were frustrated by some Django design decision, but ultimately I walked away really happy with Django as a framework. In the past I have used Rails and Pylons and so far I prefer Django and will likely use it as a starting point for most of my web development, at least until I can start using Clojure more often.
I think you mean HttpResponse object. We must use Django differently (Do you use templates and contexts?) I don't understand what you are saying in your bafflement paragraph. And your evaluation of good for simple but not for heavy lifting is the exact opposite of mine. I love Django cause it makes the simple, simple and and the hard, possible.
Each view function takes a Request + parameters and returns a Response. Simple, consistent, and flexible. Easy to write decorators. Easy to reuse view functions, easy to compose view functions from parts. Easy to ditch the whole thing and roll your own.
Django is extremely well decoupled. It comes with all sorts of batteries included but it's very easy to take out a battery and use your own. Templates, storage, url routing are all easily replaced. Apps can come and go, middleware can come and go. And most the functionality admin/auth/caching/templates/storage backend/sessions/etc are split out into apps and/or middleware so it's easy to replace/extend if you need to do something special. Recent releases have made even made the admin much easier to customize without wholesale replacement.
I've even used Django for non web apps. I didn't have to do anything particularly special. It just worked.
P.S. If you think "media"/newspaper sites are simple, you don't know newspaper sites.
I have 5 django sites running at the moment and can't say that there are any deployment issues I came across. And its only getting better now that we gonna probably see "multi-database" support I'm guessing in ver 1.2
For all of its innovation, I'm a little surprised that the Rails community hasn't put together a quality solution for this problem yet. I assume the ORM differences are a part of this - Django's ORM (I think?) defines the schema in the application, while ActiveRecord gets this from the database directly. But does that really make a Django-style admin impossible with ActiveRecord?
We opted to go with the web2py framework at work but I have been giving Django a long, hard look for some of my personal work.
> Now, I know that when I drop the f-bombs and do crazy shit like disagree with people they get their panties in a bunch and call it trolling
Actually, no, folks DON'T tend to take simple disagreement as trolling.
However, it's crucial to Zed's self image as an "outlaw rock-and-roll biker" that his opinions not be accepted, and that he be a renegade, so he has to remind us each and every time he posts "hey, look at me - I've got an opinion. Isn't that just so DARING of me?"
Yawn.