views:

1502

answers:

7

I'm just starting to use Django for a personal project.

What are the pros and cons of using the built-in Admin application versus integrating my administrative functions into the app itself (by checking request.user.is_staff)?

This is a community wiki because it could be considered a poll.

A: 

It really depends on the project I guess. While you can do everything in the admin, when your app gets more complex using the admin gets more complex too. And if you want to make your app really easy to manage you want control over every little detail, which is not really possible with the admin app.

I guess you should see it like this:

Using django admin: save time writing it, lose time using it.
Rolling your own admin: lose time writing it, save time using it.

Koen Bok
I'll probably spend the time rolling my own admin, then.
R. Bemrose
-1: It's not a simple trade-off. 80% of what you need is built in. Less than 20% needs to be hand-constructed.
S.Lott
-1: No reason to waste time rolling your own replacement until you _know_ it's worth the time.
Carl Meyer
-1 from me too. I find the Admin to be remarkably malleable.
andybak
-1. Flexible admin, easy to extend, more than makes up for having to tweak.
Nick Presta
+10  A: 

I would use Django's admin app, for a number of reasons. First, writing an administration app may be quite tricky and take some time if you want to do it right, and django.contrib.admin is for free and works out of the box. Second, it is really well designed and very nice to work with (even for non-technical users). Third, it covers a lot of the common cases and it doesn't seem wise to waste time on rewriting it until you are really sure you cannot do otherwise. Fourth, it isn't really so difficult to customize. For example, adding akismet mark-as-spam and mark-as-ham buttons was really a piece of cake.

Ryszard Szopa
+1: for a few key transactions, you might roll your own. For most transactions, use what's built in.
S.Lott
+1  A: 

I found sadly, that the while the django admin app saves a lot of time at first, it becomes a hinderence later on, as your costumer demands more features that are not easily integrated with the default admin interface. You might endup with two kinds of admin tools: the django admin (for apps that require simple data entry), and your custom rolled admin interface for other applications that require a richer interface.

hasen j
+3  A: 

It's so easy to selectively override parts of the admin in varying degrees.

You can:

  1. Override admin templates on an app by app basis or even model by model basis.

  2. Override admin views by inheriting and subclassing

  3. Catch admin url's by putting yours before it in urls.py and provide your own interfaces that are based on admin look and feel

...and lots more.

So start with the admin and then slot in whatever custom functionality you need where you need it.

There are a bunch of apps that do clever things with the admin. For example:

  • django-reversion takes over the admin-log and extends it into full history.
  • Tusk CMS combines the django-mptt app with JQuery nested sortable widget in a neat way.

Also search django-snippets for admin related snippets and this page has got a wealth of info.

andybak
+1  A: 

Consider using the Django admin, but with your own hand-crafted widgets for particular fields. You can create sophisticated form-parts, and tell the admin to use your code for the inputs and displays of any specific field, or all fields of a type.

Jannis has done some cool stuff, and his work shows you how easy it is: http://jannisleidel.com/2008/11/wysiwym-editor-widget-django-admin-interface/

A project that I am working on recently incorporated a time picker that uses drop-downs for the various parts of time, (h, m, s) Another field would indicate which days of the week were recurring... it would use 7 checkboxes for the days of the week, and store that in the database as a pickled dateutil.rruleset. Then, you just give the admin hints on which widgets to use for the various fields.

It involves defining your data class, your own widget which subclasses forms.Widget, your own Field which subclasses forms.Field, and a model.Field too. Each of the three classes is nice and simple and clean, and is responsible for a transition from the database to the Model, the Model to the Widget, and back through those two steps. It's really a thing of beauty.

The fields you create will be some of the most reusable, sophisticated intellectual property that you can accumulate... and you don't have to write your own admin from scratch.

Jim Carroll
A: 

I'd recommend enabling the admin site on just about every type of project. The cost of setting it up is pretty low, and it gives you a reasonably convenient mechanism for inspecting and modifying your site.

If your site has mostly a one way flow of information, from webmaster to visitors, then the admin site is probably all you need.

If, however, your site has a richer interaction among its users, you will need to compose django views that can enable that interaction while also limiting access to what users can really do.

TokenMacGuy
A: 

I'd go with the Django admin functionality, over writing your own. You can customize the Django admin by adding your own templates for the admin, your own widgets, etc. I'm working on a project with a very customized Django admin. If we had decided to write it by hand, it would have taken 4 times as long to get done. I just can't see a scenario where you would want to write your own.

Gromer