In response to this comment to this blog post:
Question: “It’s interesting no one is comparing Django to Plone, no?”
Okay, I’ll give it a try. :-)
I have production sites in Plone and have been working with Plone full-time for 2 years. But I’m happy and eager to flirt with other frameworks, and I’m very eager to start playing Django.
Plone is a CMS that is heavily customizable (that’s what it’s marketed as–at least). Django is a generic app framework that you can use to build a CMS. The difference might appear to be mere semantics, but I don’t think so. Plone provides tons of functionality, but also expects tons of loyalty and dedication from a developer to take it all in and become productive. Plone specifically decided to not market itself as a generic app dev framework, unlike Rails or Django. Plone is not generic enough to please your average PHP or Rails dev. However, if you’re willing to do things the “Plone way”… Plone is a pretty decent framework to write custom stuff with.
Okay, time for more specific comparisons:
Data mapping to relational databases. Plone has some basic support for relational databases via ZSQL Methods, Archetypes, and APE, but these are not as straight-forward to work with as Rails’ Active Record, Ian Bicking’s SQLObject, or Django’s Model API. This situation is changing in Zope/Plone land thanks to cool projects like Hornet and sqlos. However, Rails and Django are way ahead of Plone when it comes to ORM. Data mapping to my Oracle databases is my biggest frustration with Plone and where I most often bump into those “fighting the framework” moments. That frustration has led me to evaluate alternatives like Rails, CherryPy+SQLObject, and now Django. I haven’t tried Plone+Hornet, yet… so we’ll see how that goes…
In addition to the generated HTML UI, Plone gives you WebDAV, FTP, and XML-RPC access to most URLS/objects “for free”… This is often handy, and doesn’t look like it is there in Django, yet.
With Plone, the UI work is done for you, including CRUD forms for the objects you create and other UI forms like login, password changing, and site navigation. And you can customize it when you need to, without too much pain. Rails does provide scaffolding, but it is only a starting point, not a useable “deployable” solution. (This was on purpose and is okay– if that’s what you need/want.) From what I’ve seen of Django, Django provides a more “ready for production” UI than Rails, and I like that. I’ll be playing with Django to see how much of the auto-generated admin CRUD forms in Django I can present as data entry forms to users, instead. It looks like Django sits somewhere between Rails and Plone in the auto-UI-creation department.
Process workflow and security granularity (roles, permissions, ACL and all the combinations and intersections) – Plones beats Rails and Django… It appears you are on your own when it comes to securing your Rails app… Django is somwhere in the middle between Plone and Rails on this.
Internationalization – Plone puts in a huge focus on multi-lingual translations and internationalization support. Plone wins here because so few other frameworks care as much as the Plone developers do about this.
Accessibility – AJAX is cool, but making sites accessible to the blind is still important. The Plone devs take a more cautious approach to adding fancy JavaScript bells and whistles to the UI. I have a hunch (but this is only a hunch) that Django is taking the same cautious approach as Plone when it comes to AJAX support. I can’t help but think that Rails is hyping AJAX support at the expense of accessibility concerns.
Personally, I don’t require the internationalization or accessibility features of Plone, but I can understand there’s a market need for them. However, I do appreciate and require the crazy security options that are made available to me in Plone. Neither Django, nor Rails, yet match Plone in the security options department. But I’ll be watching that space closely.
Concerning security, there is the salted hash login generator for Rails, which will secure your app – it even gives you support for stuff like signing up accounts and emailing lost passwords for free. There is also an internationalisation module for Rails, although I haven’t used it myself.
The Ajax accesibility issue – well, there is nothing inherent in the Rails approach that stops people using it in an accessible way – I think you’ll find that many people using Ajax outside of Rails aren’t considering the accessibility issues either. And don’t get caught up with blind people – if you want to support them you have a whole lot more work to do than not using Ajax – accessibility is about making websites accessibile to as many people as possible, and that includes people with older browsers (note I said accessible, not looking and behaving the same – the two are very different).
Link | July 18th, 2005 at 4:43 am
Yes, Rails’ login generator provides good “authentication” security, but I also need good “authorization” security. I see that Salted Hash provides some authorization hooks, but I can’t find helpful docs on this. After reading the Rails documentation and a fair amount of googling… I’m left with the impression that authorization is largely “roll your own” and “good luck” kind of stuff in Rails.
Here’s a a summary of what I consider “authorization” security:
I want joe-user to be able to edit only his data, and I want joe-user to be able grant read/edit access to other friends of his choosing, and I want some folks in Finance to edit anyone’s content, including joe-user’s.
The common pattern for this is with roles and permission lists. Joe has a “user” role and has the “create timesheet” permission. Suzy in Finance has the “finance” role, and thus inherits the “create timesheets for anyone” permission. And sharing is taken care of with “grant” options.
This authorization setup is “been there, done that” kind of stuff in Windows, Linux, ERP apps like PeopleSoft, and relational databases like Oracle, and in Zope/Plone. I’ve had a tough time trying to find how to do this kind of thing in Rails and CherryPy. (I don’t want to pick on Django too much on this point since it is so new, and I’m still kicking its tires.)
The Rails wiki chapter on security covers plugging security holes— not authentication, nor authorization. The Salted Hash Login Generator wiki page has a big warning at the top saying “This appears to be broken in rails 0.13″. And many blog posts I read about “my first rails app” seem to mention the work they did on rolling their own user permissions models and code.
A famous post comparing Rails to Java briefly mentions rolling his own security authorization. (http://www.relevancellc.com/blogs/?p=31) When the post was slashdotted, no one seemed to comment to the fact he had to write his own authorization code. (This is odd to me, but maybe no one else thinks so?) I see that the table of contents in “Agile Web Development in Rails” includes a sub-section called “Limiting Access”, perhaps that is what I’m looking for… But do I really have to spend $22.50 to get this kind of information?
Maybe this kind of stuff is just so much easier to write in Rails, but I doubt it. Plus, I feel authorization is something that should be in the framework, with lots of eyeballs looking at it to plug holes in the common parts. Imagine if you had to roll your own user, roles and permissions machinery on every OS install you did!
I’d be very, very happy if I was proven wrong about this, and someone could point out Rails’ philosophy on roles, permissions, and user access. (Perhaps I should ask this question on the Rails mailing list or IRC before I make any more sweeping generalizations. :-)
Link | July 18th, 2005 at 11:20 am
Regarding internationalization and accessibility… Because Plone is more of a customizable application with lots more done for you already than in Rails… there are far more “guide posts” for you to follow on these two issues. Most of the Plone UI is multilingual out of the box (perhaps a reason it is so popular in Europe!), and is already compliant with US Section 508 (http://www.section508.gov/). If you play by Plone’s rules on these topics, there is less work for you, the app developer, to do if you care about these things. But sometimes, those rules can feel restrictive if you don’t care about it and want to be more creative in your UI design.
Link | July 18th, 2005 at 11:29 am
Salted hash. Must taste funny. Plus, you’d be thirsty and have the munchies.
Link | July 18th, 2005 at 7:14 pm
I’ve gotten a similar impression regarding authz with Rails. Also with CherryPy, Mason, etc. etc. — almost every other webapp framework out there.
Pretty much always comes down to numerous people saying “it’s dependent on your specific situation”. Seems to me most of the time it isn’t though, and what makes Rails (and others) so handy for rapid dev is they acknowledge most apps are similar in more ways than not. But still most leave out this component. I don’t understand why really…
Link | July 18th, 2005 at 8:02 pm
Authentication is hard. Zope authentication seems nice, until you need to do something non-standard and it kicks you in the ass. The new pluggable auth stuff will probably help tremendously there, but up until that it was pretty hard to work with. It’s not Zope’s fault exactly (though there was some early misdesign of the auth system); Zope (as mentioned here) tried what other Python systems (and Rails and PHP) didn’t try.
Ultimately, though, I don’t think applications are the right place to handle authentication (authorization definitely, but not authentication). It works fine when you have one app. It works fine when you are a 100% Rails, or 100% Django, or 100%-whatever shop. But really, how realistic is that? If there’s anyplace that is ripe for inter-framework and inter-language cooperation, authentication is it.
Link | July 19th, 2005 at 1:12 pm
Yeah, authentication and authorisation. That is such a pain.
It’s the main reason I’m sticking with Plone.
But yeah, I agree with Ian Bicking. A while back, why didn’t anyone develop something in Apache to handle universal authentication.
I mean, try explaining to people in a company intranet that, yes, they need to log into Bugzilla, and yes, they need to log into the CRM…
Link | July 19th, 2005 at 9:39 pm
Lonely Lion - Django First Impressions wrote:
[...] ntil I try and build something substantial with it. Paraphrasing what Jason writes in his blog Django is sort of between Myghty and Plone in terms of the ratio of what you get for free, and how much y [...]
Link | August 4th, 2005 at 4:38 pm
Groovie wrote:
Making Decisions for Others
_Reading the last post would help greatly for this one, and I should note that this post does end up comparing aspects of Django with Rails _ As I mentioned in my last post, Rails has been greatly helped by…
Link | August 5th, 2005 at 8:28 pm
Swappable authorization systems should be standard on all web software. Every bulletin board, bug tracker and CMS should have a standard swappable authorization API. It is such a common problem that people are chained to some old bulletin board and somebody else wrote their own auth for another part of the site etc…
While Rails has one auth system currently, there are others for Rails and there will be other still to come. Which is at is should be I think, not that Rails HAS such and such a system.
For my own framework (PHP) that I have used for several clients, I have all the auth and user access functions defined in one file, and I have been able to insert my app into drupal, twiki, xoops quite easily.
Link | November 22nd, 2005 at 9:58 am