The last four years or so have been virtually only Plone for me. This last week I've been using Django for a customer project: a small project with no CMS functionality whatsoever. Just some authentication, some storage of data in sql and showing the data. My colleague had previous django experience and knew about a couple of django add-ons that we could re-use to get 50% of the functionality done for free, otherwise we would have probably tried our hand at Grok (which I can't wait to do a real project with!).
Here are some random comments about my first week of Django.
- Light-weight. That's really something completely different from the towering stack that is Plone. Change a .py file and django will just restart itself. It can do that as it just takes one or two seconds to reload. Real quick development that way.
- Simple customization mechanism, especially for templates. Basically what Plone had with the portal skins. With two differences that make it a bit more maintainable. (a) by convention, every add-on stores its templates in a subdirectory named after itself. So that does away with many name clashes and the one-global-namespace problem Plone had. Just a simple convention. (b) There's a list of template directories in the global config file. That's the order of directories in which Django searches for templates. I'd say that feels much more practical than anything that plone has right now. Genericsetup's skins.xml tries to make it configurable what the order of skin layers is, but you can stack them. And the order in which the various skins.xml files are executed matters. Unless you take it all into your own hand and do it in code. And don't get me started on the amount of effort needed to override a hardcoded template name that is called directly by some plone app's python code.
- Plone is much more out-of-the-box usable. That's a big advantage. And it is a quite specific kind of box with quite specific functionality. If that's not completely what you need, you need to modify the box. Django lets you start with nothing, but that also means you, well, start with nothing. If you need basic CMS functionality for your project with user login, common contenttypes, a ready-made UI and some workflow: take Plone.
- There's a field where plone (and zope3) play much nicer with the rest of the python world: easy_install. The 1.0 Django release isn't really on pypi. Lots of other stuff also isn't. I've basically given up using easy_install and eggs for this project. Which feels old-fashioned.
- By reading some Django documents and viewing some videos from the september django conference, I've noticed that in many ways Zope3 and Plone are actually closer to the rest of the python community than Django. Pypi is overflowing with plone, zope3, grok, buildout and generic eggs. If "we" need sql integration, we take sqlalchemy: Django has its own object-relational mapper that isn't used outside of Django.
- I've had fun last week. Closer to the bare metal. More python. (This doesn't mean I don't have fun while doing elaborate Plone projects! It just means that I also had fun with Django.)
http://www.pinaxproject.com