18đź‘Ť
“The Admin is not your app.”
If the customization goes beyond the trivial, write your own views.
In my experience, I leave the internal admin pages relatively untouched. Instead, I override the admin index template, where I put links to custom-written views when the user needs to do nontrivial reporting or form handling.
11đź‘Ť
I have done something like that before. It was a CMS for a university completely implemented by extending Django admin. It turned out it was a bad design descision. I had to jump through hoops to do some things.
It really depends on what the requirements are for your application. If there needs to be lots of ajax or some specific workflow extending the admin will not be the right thing to do. But I think 60% of cases can be covered by extending the admin.
It’s also excellent for building prototypes.
EDIT
OK, that was in the 0.96 days.
So far I’ve built 2 “big” sites that are in production completely on top of the new admin. These are mostly case management, data entry and reporting so they could be squeezed into the workflow of the admin. But, not without a big effort going into extending the base Site, ModelAdmin, InlineModelAdmin etc. The decision to go this way is we were pressed to do it quick. But in the first case it was a perfect fit for the requirements too. Both run on an intranet in the government sector. Both do their job fine. One with 200 tables handling tens of thousands of entries. The other one manages payments.
So, yes it’s true. The admin is not your app. However, it’s extendable enough although much of it is not documented. And it fits in most basic enterpresey workflows. So it’s worth considering in a limited number of scenarios.
- Display foreign key columns as link to detail object in Django admin
- Celerybeat not executing periodic tasks
9đź‘Ť
I disagree with most of the other answers.
Simply put, there is no match for what you get for free using the admin app.
Your first customization of the admin will be tough as you’ll be facing a steep learning curve (you will need to deal with overriding templates, Managers, ModelAdmins, probably use database views, the CSS and JS, some additional forms and validation rules, etc…). But once that is done, you’ll start to feel king in bending the admin system to your needs. I have built a complex inventory and accounting web application with data-entry, reporting, and permission system all based solely on the admin interface and back-end.
- How can I create an encrypted django field that converts data when it's retrieved from the database?
- Order queryset by alternating value
- How to render a Django form with RadioSelect without getting a checked radiobutton by default?
- ERROR: Invalid HTTP_HOST header: '/webapps/../gunicorn.sock'
- Getting a list from Django into Javascript as an array
3đź‘Ť
The Django Admin is incredibly flexible and can be overridden in multiple ways. Unfortunately there is more than one way to do the overriding and some of the techniques are not terribly well documented.
The good news is that the following strategy seems to work well:
Override, customize and subclass the admin app until it all starts feeling a little painful and at that point just drop into your own views where needed.
There’s some useful links in my answer to this question
1đź‘Ť
In short:
Try out the admin part for your needs. Modify the standard views. If there is something missing, you can always develop your own view.
For me, I can’t imagine an entire (bigger than rolodex) application based only on django-admin.
A.
- Accessing django project in LAN systems
- Google App Engine Application Extremely slow
- Unable to encode/decode pprint output
- Django rest auth email instead of username