Upcoming Webinar: Integrating Drupal with Enterprise Back-Office Systems to Deliver a Best of Breed e-Commerce Site http://is.gd/5SUBI

And later it will be available at
http://acquia.com/community/resources/recorded_webinars/

Well, what do you want to know about them?

…and what database it supports?

Right now it supports sqlite, PostgreSQL, MySQL, and Oracle. There is also discussion about adding support for non-relational databases here.

drupal programmers
drupal vendors

Actually, WordPress does have it’s own equivalent to Drupal’s ’sub-themes’ referred to as ‘child themes’. Anyway, interesting article.

The world is changing so fast. @shacker wrote:

Django makes no assumptions about the needs of your organization or the shape of your data, which means the end product should fit your organization like a glove. Django projects are built up to fit the organization…

For small and medium sized businesses and non-profits, non-enterprise solutions, it’s often a mistake to tightly build a solution around a “glove” because the glove is going to be changing soon. Many argue that an org should fully develop a spec independent of the platform. Initially that certainly couldn’t hurt. But in many instances it’s not healthy for an org to take it’s “requirements” too seriously because often they are brand new or part of a legacy work-flow that was never that good. It’s no sin to play to the strengths of a platform, when appropriate.

In many cases it can be incredibly efficient for the spec to bend to the CMS rather than the other way around. Developers sometimes take a spec too seriously. Sometimes that is because they are trying to listen hard to the client while not knowing much about what they do. And it may be partly because of increased fees that might accrue from custom coding to a specialized work-flow.

For an enterprise ap where the requirements are set, it makes no sense to use Drupal. It’s in a quickly changing world where every business and org are trying to communicate with constituents in new ways in which Drupal will lead and thrive.

While this is a well elaborated comparison of the two, I need to ask one question.

Why would non-technical management need to have a say in this matter? If you can have management that is “non-technical”, then it’s very likely you have a bunch of technical people.”

Why would non-technical people make decisions on whether to use Drupal or Django? Because they are the decision-makers in most organizations. They write the checks, sign the contracts and have to work with leadership (and sometimes, the board or a sponsor government agency) to get approval for any project. If you don’t get non-technical people on board for a project, it doesn’t happen. The Webmaster, though the most-technically savvy person in an organization, is often more likely to be an adviser than to be the decision-maker. Given that the CMS will be used for several non-technical purposes, those needs will prevail over the non-technical aspects.

Also, if you are running a nonprofit or a small Web operation, there will be several people involved in managing the CMS. A Webmaster will not be able to handle all the technical issues alone; the director of new media at an organization, for example, will also play a hands-on role as will the marketing director. Those folks, although not the technical masterminds of the organization, will be the ones making the key decisions when it comes to CMS selection and implementation. And they will have several other issues (including customer relationship management, cause marketing and even community-building) to weigh alongside the technical issues.

Thanks for the great write-up. I first stumbled upon the article while it was still in draft and have been checking back since. The comparison of Drupal and Django has been on my plate recently and the article along with the comments has provided confidence in making my mind up.

I have little experience with either of these, much less with Django. Given this, I unfortunately don’t have much to add to the discussion (yet) when it comes to comparing the fruit in the bowl. However, what a lot of commenters seem not to understand is that this is a business comparison. If you build a house, will the factory built modules (they do those in Scandinavia at least) give you the desired outcome, or do you want to have it custom built from the ground up to suit your preferences?

It is also mentioned, that the two options being weighed already have a foothold in the current organisation. Shoving either of these at an organisation with, lets say a heavy .NET/Windows base would not necessarily be a good thing for anyone, depending on what you would intend to do with Drupal/Django. It all depends on a number of moving parts in the business and the resources at hand. So, in this respect comparing the two still holds a valid business argument in your case. Choosing between the two is then down to checking them against the business requirements.

If you are in the happy scenario, where Drupal/Django are a viable option, then to me it’s all about choosing the right tool for the job. Personally, I like to work with only the essentials, work from a clean slate up and keep my code super tidy and front end code totally under control. If the business requirements cut it, my choice would be obvious: Django.

I appreciate the article, and I would like to try out Django sometime. But when every problem with Django is described as a minor problem that will go away or can be ignored, but every problem with Drupal is described as a hideous show-stopper, it really does show a bias in big glowing lights, to me.

That said, I make a very good living writing Drupal code.

John

WSGI: This is not merely a method for hooking up your application to a web server (aka mod_wsgi) but is an interoperability shim that allows for “middleware” to be wrapped into your application. Even a relatively passive WSGI consumer application (which some might argue Django is) can still take advantage of this flexibility.

For example with just a handful of lines of code I can wrap most any sensible Python web app/framework with an interactive debugger that allows me to explore exceptions and variable states at the time of exception – even see code snippets from each layer of the traceback. I don’t have to write this, or **modify a single line of my application code** — another toolkit, Paste, (or a prettier example from Pylons) gives me all that capability for free.

Personally I prefer slightly less opinionated frameworks than Django; If I were looking for a Django-like experience, Pylons or Turbogears would likely be where I would cast my eye simply because they were designed from the start to enable the wholesale swapping out of major components (like an ORM or templating system) while Django prefers to be something of a closed single source ecosystem albeit a highly productive ecosystem.

One nice thing about WSGI is that it allows for a certain amount of bridging the two solitudes, and as I pointed out in the debugger example, often this can be done with quite literally four or five lines of integration code.

Interactive console: Django / Python offer a fully interactive command prompt where you can directly manipulate your data objects; it’s an incredibly powerful tool not only for working with the application data but also for quickly proving out snippets of code. Out of the box, if your OS supports readline you can have tab expansion/code completion, and with some minor tweaks you can even have syntax highlighting if you want. PHP has nothing comparable.

Indeed virtually any common Python web app framework exposes this type of capability because Python itself makes it almost trivial to do so.

Python as a “feature” of Django while touched upon in the article and comments is a key differentiator that is probably not stressed enough. I’ve mentioned the interactive prompt as but one feature; Unicode handling is another; it is sane and has existed in Python for many years; with Python 3 I would argue Unicode handling moves beyond sane and approaches “easy”. Consistency is a “feature”; you won’t find dozens of compiled in functions that purport to do what others do. You won’t have to recompile your Python just to get X or Y feature enabled, just “import something”.

Want a standalone test environment on the same box as your server? No problem, there is “virtualenv”, a stunningly simple method of creating little mini standalone Python environments to avoid polluting your system Python or your production environment.

Packaging works well, and is being continually improved (distutils / setuptools/ distribute / pip et al). You can write an application that has a swack of dependencies and deploy a simple setup.py script which checks for and installs the right dependencies. PyPI – the Python Package Index, hosted on Python.org itself, is another key “feature” that not only enables browsing and searching for available third party packages but also forms the basis for automated installation of same.

These are but a few features and capabilities which one gets when they adopt any Python framework.

This is great in a lot of cases, but there are just as many cases where it’s not the best way forward, where Django would be more suitable.