Hi, new to the list here, but I've been doing Django dev for a while now and Drupal as well. In fact, at my workplace (60-person web design/ development shop) I'm leading a similar charge to move us away from Drupal development towards Django.
I took a look at your post and thought I'd add a few things: 1. It's not exactly correct to say Drupal isn't Object Oriented. Like Django, some of Drupal is written in a typical procedural style, some OOP. It's more accurate to say Drupal is less Object Oriented. More here: http://drupal.org/node/547518 In any case I'm not sure it's a huge selling point. 2. Same for MVC: Drupal does it...kinda. More here: http://archivemati.ca/2006/01/21/drupal-as-a-mvc-framework/ I'd say Django maintains a separation of concerns much better, though, and I'd say this is a big selling point, unlike OOP 3. +10 on templates: Drupal templates are very frustrating. A single page is usually generated by an elaborate nesting of templates. Let's say you have a page that lists a bunch of nodes. You have a template for the page, for the list, for node itself and maybe (with CCK) individual node fields. This is a lot to keep track of and why there are whole books written about Drupal templating. What's more, you don't have enough control over markup. A lot of devs where I work feel very frustrated when the lean, clean, semantic html mockups they produce get completely torn up by the way Drupal works. Django almost never forces any markup constraints on you. This allows front end dev to proceed more or less parallel with back-end dev in Django, which buys you a lot of time if you have teams that work that way. In Drupal, the templating phase is intimately tied into the back end development phase, partly because of the less-than-stellar separation of concerns mentioned in #2 above. That's a slower way to work. 4. Drupal doesn't have an ORM, really. With you can get a mapping of DB fields to a php object, so that say, the "title" DB column maps to an object : $node->title, but that's not really an ORM in any sense that I think of it. 5. Security. Django makes a lot of design decisions that make it hard to write insecure code. Not impossible, but hard. Some attack vectors, like SQL injection (and other input sanitization exploits) are pretty much eliminated by Python's DB API and Django's ORM and Form validation tools. This is not to say you couldn't create an exploit in a Django app, but that you'd have to be trying to on purpose. They also give you tools to prevent CSRF which were optional, but in newer releases are being promoted to "required" in contrib.admin at least (http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ ) One of PHPs biggest failings re: security , IMHO, is they made it too easy to do the wrong thing for far too long. This is improving, but I think you still see this lax approach reflected in the large number of Drupal exploits that have appeared and in the way many people don't seem to take security as seriously in the PHP universe. 6. Deployment. I tend to think of Deployment as more than just installing an app and for that reason, I think Drupal's deployment is far inferior to Django's. It's relatively easy to set up a Lamp stack and install Drupal on it. Django requires you to install Python, Apache, your RDBMs, python drivers to connect to it, PIL (probably) and mod_wsgi (Hopefully that's what you're using). These things represent the baseline for installing an app, IMHO, and for people without a *nix background, setting them up is harder than in Drupal (although with debian and dpgk, it's not that bad). But to me, deployment means more than installing a LAMP stack. Deployment means packaging. PHP doesn't really have good package management tools. Python does. Deployment means being able to run a test suite on your install and know immediately if anything has broken: Django let's you write tests for your app, Drupal does not. Deployment means being able to maintain dev, staging and production environments in sync. In Drupal this is very hard: one of my biggest complaints is that Drupal is that it mixes application configuration and data in the DB so that they are completely inextricable. This is a huge problem if, for example, you want to migrate some new views from your staging environment to your production environment. Deployment also means upgrading: In Drupal you've got the upgrade treadmill and it sucks. The more modules you have the more it sucks. Upgrades not infrequently break things, and since you have no unit tests or functional tests, there's no way to know if something broke without clicking around and hoping you catch the problem. Django + Python give you: + package management (distutils, virtual_env, zc.buildout) + unit and functional tests + fabric to help deploy in multiple environments across the cluster + south to help you migrate schemas + a complete separation of data from everything else My argument against Drupal boils down to 2 things: 1. It's doesn't know if it want to be a CMS or a framework, and the confusion shows. It's an OK CMS if your problem set matches it's capabilities. It's not a good framework for the reasons mentioned above and more which many commenters here have caught. 2. Drupal makes deployment of a real, professional site (where less than 99.99% uptime is not an option) very difficult and there doesn't seem to be anyone doing much about it. This is a start http://groups.drupal.org/aegir-hosting-system ...but it's not enough. Anyway, from someone who has been there, I feel your pain. We've done a few parallel development projects @ my workplace to show Drupal vs. Django and the results have been encouraging. For the kind of site we often do, an average Drupal build means moderate to heavy template customization, CCK and custom content types, 20 or so 3rd party modules modules and 1 or 2 custom modules we write. If this is the kind of site you're doing, Django is very likely a better fit. On Nov 15, 7:43 pm, shacker <shac...@birdhouse.org> wrote: > On Nov 12, 4:56 pm, Kenneth Gonsalves <law...@au-kbc.org> wrote: > > > >http://birdhouse.org/blog/2009/11/11/drupal-or-django/ > > > looks like you have missed out on security - count the number of critical > > holes in drupal over the past year with the one hole in django in the past 4 > > years. btw, I tried to comment on your blog, but was rejected saying I was > > behind a proxy. Given that practically any one on a LAN is behind a proxy, > > this in practice prevents comments. > > That's a tricky area - we have to be very careful about saying that > anything is "more secure" than anything else. We don't want to give > false hopes/impressions to managers, and we have to remember that part > of the reason for Django's security track record is because it's > "below the radar" of attackers. That could change at any time. Still, > security is an important consideration and I've included a bit on it > in the "final" version, which is up now. > > Thanks all for your contributions. > > Scot -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=.
