Rails and Django - Data and User Administration (part 9/15)

Data Administration

Django

One of the things that Django is "famous" for is its built in administrative features. Given a Model, the framework can automatically generate a nicely designed set of admin pages to create, retrieve, update, and delete (CRUD) items in the model. It can also search, filter, and sort the lists. All the models which you've exposed to the Admin class appear on the admin/ home page. Unlike Rails' scaffolding, the admin is polished enough that it could be given to end users in a production website (such users being content editors, not visitors).

To enable Admin features for any model, simply add "class Meta:Admin:" to the Model class and refresh the page. Sweet!

However, as great as it is, I am told the code is very difficult to modify. So either you like and use it, or you're better off writing your own from scratch. This situation will soon change, as the newforms forms library is being integrated into a new Admin app, and when they're released you'll have the full glory of the slick admin interface, plus the easy custom-ability of newform. That's the promise anyway.

The Djang admin include basic permissions to add, edit, delete items. It is rudimentary but may suffice in many cases. It is limited to class granularity (operations on specific object types) not attributes of those objects. For example you cannot grant permission for a user to edit only items that he had submitted.

Rails

Rails has nothing like Django's admin GUI, in its core distribution.

However, Rails does have a number of non-core plug-ins that can automatically generate an admin interface. One is called Streamlined, and is actively under development. There is a webcast of the plugin and it looks quite slick (although I haven't tried it yet myself). (Another Rails admin plug-in called auto-admin is modeled after the Django one).

Otherwise, you are expected to write your own, as you would other Controllers + Views. Easy enough, if you don't mind.

Opinion

One clever blogger reports that on his Rails projects, when he wants an admin interface, he uses Django to administer his Rails models! (A testament to Django's ability to interface with outside databases, by the way).

I should probably give more credit to the Django built-in Admin tool, but its not very customizable (until the promised revision). Rails is catching up.

I've lumped in Permissions because its not developed enough in either framework to stand on its own.

Conclusion: Both framework's are working to improve their admin interfaces. Rating 2-2

User Administration

Authentication

The Django Admin app also has basic user management, including administering users and groups, registration, and authentication (login).

Rails has stated they do not intend to include authentication in their core product. Instead there are plugins, including "act_as_authenticated", and several derivatives of this, which provide varying degrees of user administration and permissions. You then integrate this into your application.

In an enterprise environment, including corporate intranets, authentication must often be decoupled from the system to utilize single sign-on systems or directory services like LDAP. If this is important for your application, we'll leave it up to you to investigate whether the framework offers what you need (via user contributions, no doubt).

Registration

A corollary of this is registration, which refers to signing up new users. Most systems that have user accounts need a way for users to register themselves. And perhaps generates an email requiring users to activate their account (and thus validate the request). Both frameworks provide a basic level of support for registration, via user contributions (plugins, apps).

Sessions

Where there are users there must be sessions. Sessions enable continuity between HTML pages, which are inherently state-less. With sessions, the framework can know when a subsequent request from your browser is still you and not someone else (e.g. for showing error messages in forms, or for tracking items in a shopping cart).

Both Rails and Django have support for sessions and messaging.

For anonymous users, messages are passed between pages using an object called the "flash" in Rails. In Django you can pass messages via the "session" framework.

Neither Rails nor Django does automated housecleaning of expired sessions. You will need to setup a cron job or other script to periodically purge old sessions from the database.

Opinion

Both frameworks have a long way to go towards providing mature and robust user administration and authentication tools. They're nowhere near what I'm used to in the Xaraya web application framework. Yes, I understand a "development framework" is not an "application framework", but that's no excuse (we're in the Opinion section here!).

In general, other than some basic tools and components, you pretty much have to roll your own, especially, for example, if you need to build an advanced multi-user application with various groups and permission levels. I would love to see some seriously useful admin, user management, registration, authentication, and permissions tools to build upon.

And to be honest, I really need to play with both Rails and Django more, including any plug-ins and apps, to confirm or refute my concerns.

Conclusion: I rate both the same low score of "2".

Postscript: I recently discovered a Rails generator project called Goldberg that looks promising.