Harry January 10, 2007 at 12:56 p.m.

Having played with Django, I'd question why you'd use it to create a CMS when it doesn't provide any of the standard building blocks of one. Especially if one discounts the auto-admin, which both the docs and people using Django say is the right thing to do ("write it yourself")

binnen January 10, 2007 at 1:47 p.m.

I agree with Harry. I can´t really think of using Django to build a CMS easily. The auto-admin is fine, though it´s kind of limited (and it hasn´t been improved for almost a year now).

James M January 10, 2007 at 2:12 p.m.

I disagree with both of you -- I've done it twice. Clients very pleased :) Got teh money just before Xmas.

Matt January 10, 2007 at 2:19 p.m.

Ooh, there's a sale at Penney's!

Alberto January 10, 2007 at 2:56 p.m.

@Harry+binnen
Are you kidding? Django is probably the best framework to use if you have to build a CMS! In fact it was extracted from the a real world CMS (where Rails was extracted from a very different application such as Basecamp). Some Django features (automatic admin interface, elegant URL design, cache system, internationalization, flat pages, etc.) are especially useful in a CMS scenario. Moreover the most famous Django application is a successful CMS: www.ellingtoncms.com

binnen January 10, 2007 at 3:15 p.m.

@Alberto: on ellingtoncms.com it says that ellington is an "online publishing system", which in my view is NOT a CMS. if it´s so easy to build a CMS with django, why isn´t there anything out there yet? James M said he did it twice. why not show it to us? i´m probably just disappointed with the oh-so-praised admin-tool. sorry for that.

Alberto January 10, 2007 at 3:38 p.m.

@binnen
what is your definition of CMS? Can you point out some examples?

binnen January 10, 2007 at 3:57 p.m.

@alberto: key-issues are role-management & workflow management, tracking multiple versions of a document (revisions), date-based publications, assign different (pre-defined) templates to new and existing content - what Typo3 does with TemplaVoila, for example, digital asset management ...

regarding the terminology, the django auto-admin (for example) is a very simple tool for updating content (not more, not less). with a CMS, i´m having building blocks, modules, themes and so on.

btw, i´m not saying that it´s not possible to build a CMS with django: i just think it´s weird to write something like "Django is a framework built on Python that you can use to build a Content Management System or a blogging tool ...". of course, you can do both - with the latter being really easy to achieve whereas the CMS might be a lot of work.

Simon Willison January 10, 2007 at 4:22 p.m.

Of course Ellington is a CMS. It even says it is in the URL!

I've not seen anywhere in the Django docs or the community where people recommend against using the admin - quite the opposite! The admin is designed to be used in production. Are you sure you're not confusing it with Ruby on Rails scaffolding, which the Rails community tends to recommend against using for anything other than small rapid prototypes.

binnen January 10, 2007 at 4:38 p.m.

auto-admin: did I recommend against using the admin? I don´t think so. it´s a cool tool for updating content. it´s really hard to extend, the design is ... well, not so good and it hasn´t been improved for a while. that´s all. I´ve written that somewhere else already: we´ve moved (almost) all or our sites to django and doing the websites is fine and easy. doing the admin-stuff is just hell (well, at least doing the last 15% of it).

ellington: having the phrase "cms" in the URL doesn´t really count as an argument, does it?

Alberto January 10, 2007 at 4:55 p.m.

@binnen
Django is a framework, a set of tools to build a vast array of applications. It's neutral. However if you consider its origin and the features I remembered early, you will find that no other framework is best equipped to build a CMS.

Of course Django is not a CMS (it's a tool to build a CMS) and you can't compare it to Drupal, Expression Engine and Typo3: they are CMS.

If you need a CMS or a blog app I suggest you try an existing CMS/blogging tool (EE, ModX, Drupal, WordPress, Typo3, etc.) If you are not satisfied with them you could build your own app with (or without) a framework (Django, Rails, etc.)

Consider JeffCroft.com: you can't build a similar site with an existing CMS/blogging tool (too many hacks required!). Jeff used Django to build a set of custom apps which manage the contents he produces (post, photos, links, etc.): in fact he built a new wonderful CMS!

Alberto January 10, 2007 at 5:09 p.m.

2 little add-ons:

Don't forget: when your site is powered by a custom built CMS, this unique app could represent a competitive advantage. Instead, if you use an existing CMS package (available to everyone), you have only design and content to differentiate your offer from your competitors.

If Ellington is not a CMS I'm Paris Hilton :)

Jay Baird January 10, 2007 at 9:03 p.m.

I have to disagree with the above poster mentioning the admin is hard to extend. I whole heartily disagree. Sure it isn't for the feint of heart but it is easy to short circuit URLs going to the admin to go to your own views. Just open up the files and use the power of python to do what you need to get done, and as a user of Ellington I can tell you it manages content quite well.

If you need examples:
www.redding.com
www.courierpress.com
www.reporternews.com
www.dailycamera.com
www.abqtrib.com
www.buffzone.com

Or for a non-newspaper example our papers use django to track and add all of the high school sports stats for eleven markets. For example: http://stats.prepxtra.com/basketball/...

binnen January 11, 2007 at 3:55 a.m.

@Jay: why I think the admin is hard to extend? first, because there is html-code in the views. it´s not possible to change things just by changing templates (yes, sometimes it is). second, the html/css is a mess (so it´s really hard to make a skin for the interface). third, noone is interested in improving the interface (questions are not answered, improvements are declined, responsibility is not clear after wilson left the team). I had this discussion before, and I know that people think the auto-admin is oh-so-great. after doing about 10 sites with django my experience is, that it´s getting really complicated with bigger sites. discussion ends here. take a look at the screencast of the symfony admin-generator and you know what I mean (http://downloads.symfony-project.com/...).

@Alberto: it probably comes down on your definition of a CMS (which is, obviously, quite different from mine).

João Marcus January 11, 2007 at 6:46 a.m.

@binnen: Sometimes the question is: do you *REALLY* need complex workflow management, complex document revisioning, etc?
I've done such a complex website once, using Plone. Nobody cared about the workflow, the revisions, etc. They only cared about one thing: Managing the website was ridiculously difficult and cumbersome. And so the website was only being used to let users download software updates.
CMS's manage content, and that's it. The real issue is how complex are your content management needs. You may need complexity, while others don't. My company needed integration with its ERP system, and that's what we built. It was way more important than workflow. So, right now, all products' data (description, features, etc) live inside the ERP.

Adam Blinkinsop January 11, 2007 at 10:07 a.m.

binnen wasn't the one saying that use of the auto-admin was being discouraged -- that was Harry.

As for me, I think that the showstoppers for building a complicated CMS (for a large corporation, desiring a large, complicated app), are revisioned database migrations (which are rumored to be in the works) and a version 1.0.

Is that the kind of CMS you're talking about, binnen? I think that for smaller companies, with simpler needs and expectations, Django would make a great framework -- with a desired configuration of Apache+mod_python and PostgreSQL, it's cheap to run and easy to set up.

A larger corporation (I work for Columbia Sportswear) might balk at the recommendation of a free dbms, a "scripting" language, and the pre-release version number. Even though I consider this the best web framework I've come across, it might not look too good to a corp. working with Oracle or Java, etc.

Of course, I haven't used it to create a major CMS yet, so who knows? Perhaps the CMSs that James M made are full-featured, massive apps. :)

Anonymous January 11, 2007 at 3:10 p.m.

I am grateful for the admin interface as is, but the lack of preview and review mechanisms built in I think is a major issue, after all it is at least a content publishing system and in a production environment clients need to review content before publishing. Adding these mechanisms alone alone would be a big improvement, even without consideration for the other features of a full-fledged CMS.

Daniel Lathrop January 12, 2007 at 8:45 p.m.

I think some folks here are expecting a bit much of a Web framework. The admin interface doesn't have a feature you want? OK, then create a view and a controller that have those capabilities. It's far easier than it would be using Perl, PHP or Python on their own.

For example these comment forms have a preview function.

I won't do a Rails-vs-Django comparison on that issue, since I'm not qualified, but everyone seems to agree that python's built-in admin capabilities to Rails. As for symfony, watching that video only convinced me that I have no desire to use symfony.

Maybe it's that easy things are SO easy in Django that people are surprised that hard things are still kinda hard. The other frameworks out there don't make easy things as easy as Django does (IMHO), so it's a smaller jump to the hard things in those because you're already having to muck around so much to accomplish anything.

Daniel Lathrop January 12, 2007 at 8:47 p.m.

"python's built-in admin capabilities to Rails" --> "Django's built-in admin capabilities are superior to Rails'"

My apologies.

Alberto January 13, 2007 at 2:27 a.m.

I agree with Daniel: some people are expecting a bit much of a web framework. They mistake frameworks for CMSes.

James M January 14, 2007 at 8:10 a.m.

"James M said he did it twice. why not show it to us?"

Doh! You got me there. OK, I fibbed ;)

Here's how it works: design your models, create some templates, bolt it together with URLs. Use TinyMCE in the admin interface so the user has some WYSIWYG. I often include a simple "Page" model, which can be attached to a location by calling "/page/this-is-the-page-slug/" to provide more flexibility to the users. Sometimes I include a boolean "Include in navigation?" so that page can be shown in a menu-bar or side-bar, whatever.

Other times, I code for specific locations so there might be a page called "/donations/" for collecting donations. The part of this which can be changed is the intro text (maybe a couple of paragraphs) which appears on that page. Then there's some form-work to get the donation amount, etc.

I might post some kind of tutorial about this, but you can work it out for yourself from the Django tutorials (one of Django's greatest assets, btw, at least for novices).

Just because you wouldn't use Django as a CMS (or to build one) doesn't mean I can't. I have, I was paid good money for both of them, and the clients are very pleased :-P

HTH.

Gary L January 14, 2007 at 2:18 p.m.

Django's admin could charitably be called a double edged sword, or uncharitably "bait and switch".

It's great out-of-the box and works- gives you free CRUD for models, and you can restrict permissions as needed on a model-by-model basis. It's fast. It has some slick built-in customization options (like searching and in-line editing). Changing the look isn't so hard. On the other hand...

If you want to add a field saying who was the last to modify a record, and have it automatically populated with whomever is logged in- you'll hit some hurdles. There's a choice of ugly hacks for it, true, but Django's design purposefully makes it difficult to get the admin user from inside a model, since that would weaken its abstraction.

That also means you can't easily code something like "the person who created an object (a blog post, an article, etc) can change it, but others can only read it" in the admin.

Or add workflow to the admin.

The admin templates are full of custom template tags and filters, not the most friendly for developer re-use.

Especially considering that there's a whole "forms" package (being replaced by "newforms") for helping with your models' CRUD- which the admin package doesn't use! C'mon, eat your own dogfood, rewrite the admin to use newforms, and we'll understand it much better...

Now I've only written one app with Django, and I'm still writing it. I got paid and the admin made it possible for me to say "Step 1 is done," I'm thankful for it, and I'll keep it as a superuser option. But when it comes to having general users create, update, delete objects, they won't be using the admin, or any templates or objects derived from contrib.admin, or even the Users model- it's easier for me to write what they need from scratch.

(Sorry for being longwinded- I got riled up when I saw people taking issue with Harry's first comment. I also was discouraged by the Django community from re-using the admin, something along the lines of getting an answer "it always amazes me how many people try to make the admin their whole app" to some question.)

Adrian Holovaty January 14, 2007 at 3:21 p.m.

Gary L: Get excited! Pretty-much everything you're asking for is on its way soon. See the brand-new newforms-admin branch:

http://code.djangoproject.com/wiki/Ne...

And a small correction to your comment: The current admin site *does indeed* use the "forms" package. But in the newforms-admin branch, I'm reworking the admin site so that it uses newforms instead of "oldforms."

Alberto January 15, 2007 at 3:13 a.m.

I suppose the newforms-admin branch will be merged into the trunk before 1.0 release. What about the Django Book? Should its treatment of the admin interface be updated to reflect the changes in the newforms-admin branch?

Jaroslaw Zabiello January 15, 2007 at 11:37 p.m.

Python has already very good CMS - Plone. Django is great project but it has also many limits. Eg. it allows for only one database for all its applications inside project (this is main reason I could not use it in my project). Another one: its url system is much worse and less flexible than Pylons or Rails provide. There are no helpers nor wrapper around url generation. Any change in structure of application needs manual (sic!) changings in thousands of urls in all Django's templates.

Dan Kelley January 16, 2007 at 6:59 a.m.

Please, sir, can we have the deployment chapter?

João Marcus January 16, 2007 at 1:46 p.m.

Jaroslaw, I don't understand why the Django's URL system is much worse and less flexible than those of Pylons or Rails. I mean, it's regex-based, it couldn't be any more flexible. Changing the app structure doesn't imply changing the URL themselves, you can easily change the view mappings.

João Marcus January 16, 2007 at 1:47 p.m.

BTW, I use multi-db in my Django app :)

Jeremy Dunck January 16, 2007 at 1:48 p.m.

@Dan
/me checks watch.

Got a deadline? :)

Vance Dubberly January 16, 2007 at 3:54 p.m.

Well you could use it to make a CMS however it won't be a very efficient CMS. django's got one huge massive flaw that keeps it from being great for that. Namely it doesn't support table inheritance. I have to have a separate table for every type of object in my database, a good CMS uses a DB model that makes one table the basis for all content tables in the database. i.e. I may have a table called content_object with the fields id, name, slug and other tables which are mapped to that table to produce things like; image: id, name, slug, width, height, description... or story: id, name, slug, blurb, body and so one.

Not having this creates a tremendous amount of work for the developer and the database. For instance if you want to tag content you have to either create a map for every table (object) or use a single mapping table with 3 columns ( which Django also doesn't support ). A SQLAlchemy back end would certainly have fixed this problem but that seems to be dead in the water.

Another huge problem is it's reliance on it's own authentication database. This is fine for a completely self contained system but completely unworkable in the Enterprise. Sorry gotta be able to work in Kerberos and LDAP. I don't care how just let me use apache and mod_krb5, or at least give me an API to write a plug-in. You can write around this so long as you are willing to accept that Django's most touted feature ( the auto admin ) is essentially worthless.

Don't get me wrong Django is the RIGHT choice for so many types of jobs. Need a quick app for a small business, Django Rocks. Just not for anything really sophisticated (same goes for RoR). Keeping my eye on it though...

ronson January 16, 2007 at 4:30 p.m.

well - inheritance of models works

it just creates extra tables right now

since its going to change sonner or later to be more flexible in terms of how the inheritance is represented in the database it might not be whise to use it yet

Jaroslaw Zabiello January 16, 2007 at 6:40 p.m.

João Marcus: How are you using multi-db? You must be using some hacks because Django's config file contains a place for only one database. There is "multiple-db-support" project but it exists only in Django's SVN branches. Is there any chance for adding it to 1.0 release? If not, I have to use (much more flexible) Pylons framework.

The view (I hate django's confusing name conventions, everybody calls it controller) mapping is not enough. After some changins, You still have to change all links you have in every of your template. It is horrible anti-DRY approach!

João Marcus January 17, 2007 at 5:03 a.m.

Yup, I'm using the SVN branch. I don't know when it's supposed to be merged, but it's stable and *should* be merged soon.
It seems that you really prefer Pylons, so I guess that's what you should use :) My problem with Pylons is that I wasn't confident about it, I couldn't tell my boss I was using something a little bit obscure for him. Yes, that's important, in fact, it's more important than I first thought.

Jaroslaw Zabiello January 17, 2007 at 7:29 a.m.

João Marcus: I am using more Django than Pylons at the moment. And I am using RoR even more then both of them. Django is great framework, but I need more flexibility it has. I can live without url wrapper but not without multi-db. I would like to hear what Django core team think about merging multiple-db-support soon. It means: before 1.0 release will be lanuched.

JP January 19, 2007 at 1:24 p.m.

multi-db support won't be launched with 1.0.

1.0 is solely to mark a stable API. The other branches will be merged in after the 1.0 release.

Masklinn January 28, 2007 at 2:18 p.m.

João Marcus said
> Jaroslaw, I don't understand why the Django's URL system is much worse
> and less flexible than those of Pylons or Rails.
> I mean, it's regex-based, it couldn't be any more flexible.
> Changing the app structure doesn't imply changing the URL themselves, you can easily change the view mappings.

He's not talking about the URL matching, he's talking about the links in the templates: Django more or less requires you to hardcode the paths in the templates while Rails (and I assume Plone, but I haven't used it) provide helpers which leverage the routes (the url matcher) to *generate* the urls for you.

For example if I want a link to point to the "results" action/view of the "polls" controller (/application in the Django world?) while providing the pollid '70' I'll write the following in my template:

<%= url_for :controller => "polls", :action => "results", :pollid => 70 %>

I don't need to know *how* the urls are built, nor what kind of structure is seen by the user because I don't care, the helper will manage the creation of a "real" link that can be understood by the application.

Mike Robinson February 7, 2007 at 11:13 a.m.

"The hidden secret of Django," I think, is in what it calls "middleware" and "installed apps."

For example, I needed to put together an application that had a CMS, and a problem-ticket system, and an online store all under one roof, under the same authentication system and so-on. The app had to have a single "look and feel," without me writing all of it from scratch.

I needed to give parts of the thing a very strong and specific SSL-based security regime, applying to all inputs and outputs from the site.

Django could do that. Extremely... fast.

Dig in. This tool is BRILLIANT.

kreaflux February 8, 2007 at 9:40 a.m.

You can extend Django. If you don't want to hard code your links' urls, make a new tag. Want support for multiple databases? Take a look at the source code and change it. Derive a new model class. Remember you can do anything Python can do (everything). It's a framework, you are suppose to modify it to fit your needs.

Chris Brand July 3, 2007 at 4:17 p.m.

The django equivalent to
<%= url_for :controller => "polls", :action => "results", :pollid => 70 %>
would be something like
{% url polls.views.poll_results pollid=70 %}

No need to change anything there if you change your urls.

Or, as Maasklin said (about Rails) :
I don't need to know *how* the urls are built, nor what kind of structure is seen by the user because I don't care, the helper will manage the creation of a "real" link that can be understood by the application.