17👍
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.
17👍
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.
- [Django]-Name '_' is not defined
- [Django]-Sending post data from angularjs to django as JSON and not as raw content
- [Django]-Annotate a queryset with the average date difference? (django)
7👍
It’s so easy to selectively override parts of the admin in varying degrees.
You can:
-
Override admin templates on an app by app basis or even model by model basis.
-
Override admin views by inheriting and subclassing
-
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.
- [Django]-Rendering a value as text instead of field inside a Django Form
- [Django]-How do I install psycopg2 for Python 3.x?
- [Django]-Http POST drops port in URL
3👍
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.
- [Django]-Django REST Framework (DRF): Set current user id as field value
- [Django]-Django admin default filter
- [Django]-CORS error while consuming calling REST API with React
3👍
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.
- [Django]-Cannot access django app through ip address while accessing it through localhost
- [Django]-How do I install psycopg2 for Python 3.x?
- [Django]-What does 'many = True' do in Django Rest FrameWork?
1👍
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.
- [Django]-Substring in a django template?
- [Django]-Django 1.7 – App 'your_app_name' does not have migrations
- [Django]-Getting Values of QuerySet in Django
1👍
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.
- [Django]-Passing STATIC_URL to file javascript with django
- [Django]-Python 3 list(dictionary.keys()) raises error. What am I doing wrong?
- [Django]-Django apps aren't loaded yet when using asgi