Customize Django Admin Interface(appliku.com)
appliku.com
Customize Django Admin Interface
https://appliku.com/post/customize-django-admin-interface
32 comments
We have been working on something that sounds similar. It ain’t perfect yet, but we are using it quite a bit already.
https://github.com/django-beam/django-beam
https://github.com/django-beam/django-beam
The common wisdom was always not to rely on it for any of your users (for far too long) and build something separate as soon as possible. But i must admit that lately it got much much better. I only recently discovered that you can have multiple admins with it's own admin models.
So way less hacks.
I actually want to try build an app just to see how far I can push it with Django admin and see how hacks it will end up.
I actually want to try build an app just to see how far I can push it with Django admin and see how hacks it will end up.
I haven't seen it used by users, but it's amazing for non-technical staff (PMs, support to some extent, etc). They can inspect and modify the database while making sure everything still validates, run batch jobs, actions, etc and it's all very low effort to implement. No need to fetch a dev to debug an issue with data or understand whether the cron job run or why it may have failed. It helps with understanding a platform's internals, which improves understanding and communication all around.
I'm sort of fascinated by the resilience of the Django admin. It's nearly 20 years old at this point and really hasn't changed too much since I first used it in 2007. I've always thought it was a good example of what having a strong designer early in your project life-cycle can do.
Yup. No project of this size is without some ugliness, but Django really is an impressive piece of technology and complex but cohesive architecture. The more I understood its layers the more I appreciated how much it does, and how well it allows you not to worry about things until you need them.
You mentioned having a strong designer early in the project; did you have a specific name in mind? I'd love to see what they're up to and study some of their other projects.
You mentioned having a strong designer early in the project; did you have a specific name in mind? I'd love to see what they're up to and study some of their other projects.
I'm guessing Wilson Miner:
https://wilsonminer.com
https://wilsonminer.com
Yes. I was referencing Wilson. Thanks!
I am strongly considering django for the next side project. I am new to python but enjoy it’s low ceremony approach (you sort of forget what language you are using, it gets out of the way) and then django to have more bases covered including this admin. Then htmx to avoid JS, maybe Elm if it needs interactivity
Strong opinion: DO NOT break up your project into apps.
Make 1 app called core or common of whatever and replace models.py with models/<namespace_or_domain>.py and import those into models/__init__.py
Everyone jumps into apps with foreign keys across app boundaries and it makes a mess of things from the start that doesnt buy you anything.
1 app. 1 set of migrations. Turn models, views, etc into a package instead of the single file module.
Its the one thing I wish the docs would prescribe and demonstrate for new project advice. .
Make 1 app called core or common of whatever and replace models.py with models/<namespace_or_domain>.py and import those into models/__init__.py
Everyone jumps into apps with foreign keys across app boundaries and it makes a mess of things from the start that doesnt buy you anything.
1 app. 1 set of migrations. Turn models, views, etc into a package instead of the single file module.
Its the one thing I wish the docs would prescribe and demonstrate for new project advice. .
> Make 1 app called core or common
Do not call it core. There's an existing app or module or something with that name and this will introduce hard-to-diagnose bugs. Common is preferable.
Do not call it core. There's an existing app or module or something with that name and this will introduce hard-to-diagnose bugs. Common is preferable.
i've been getting away with calling the folder with models/views 'app' and the folder with asgi/wsgi/settings 'config' (top-folder name is the project name)
so far nothing bit me other than an awkward 'app' in my installed_apps, fingers crossed
so far nothing bit me other than an awkward 'app' in my installed_apps, fingers crossed
Thats a strawman. Many libs use common as well.
After many years, I’ve come to the same conclusions and can heartily recommend these suggestions!
Another similar suggestion I’d add is make a settings module with a base collection of configuration (i.e. myproject/settings/common.py) that other deployment-specific dev.py & prod.py import from.
Basically, don’t forget that Django projects are always Python modules too, so go ahead and use those language features too.
Another similar suggestion I’d add is make a settings module with a base collection of configuration (i.e. myproject/settings/common.py) that other deployment-specific dev.py & prod.py import from.
Basically, don’t forget that Django projects are always Python modules too, so go ahead and use those language features too.
After many years of experiments i came to the same exact conclusion.
In 15 years I haven't seen a single case when splitting a project into multiple apps brought anything but pain.
Also, splitting files like models into packages is also a great approach. 6 months ago I found myself with models.py, API.py (my alternative for API views vs regular views) and serializes.py each over 3k lines of code. Spent 3 days splitting them into small files by topic. Way easier to work.
I also wish docs suggested that it is an option and better to split them earlier. Because it is so easy to just "add one more model to the end of the file, what can go wrong?"
You understand what goes wrong after 2-3k LoC
In 15 years I haven't seen a single case when splitting a project into multiple apps brought anything but pain.
Also, splitting files like models into packages is also a great approach. 6 months ago I found myself with models.py, API.py (my alternative for API views vs regular views) and serializes.py each over 3k lines of code. Spent 3 days splitting them into small files by topic. Way easier to work.
I also wish docs suggested that it is an option and better to split them earlier. Because it is so easy to just "add one more model to the end of the file, what can go wrong?"
You understand what goes wrong after 2-3k LoC
Agreed. Only make another app if it's almost entirely decoupled from the main app, e.g. a blog app or similar.
Do you have a tutorial for more detailed example of what you wrote?
This tutorial addresses the practice: https://doordash.engineering/2017/05/15/tips-for-building-hi...
There's also a long, uh, spirited discussion about it here with some decent arguments going both directions: https://forum.djangoproject.com/t/why-do-we-need-apps/827/19
There's also a long, uh, spirited discussion about it here with some decent arguments going both directions: https://forum.djangoproject.com/t/why-do-we-need-apps/827/19
if not, please write one when you have time, short one is better than none :)
so, my 2 cents (and it's something i've said before here):
every time i start a project with something other than django, i end up with django, but "homebrewed".
example: you start with flask. you need auth, so you add flask-login.
you need some database access, so you add SQLAlchemy (and its flask plugin). you also need some kind of admin page, so you add flask-admin.
when you are finished, you have a flask-django framework, but not as well integrated -- with django, you get ALL of those all of those out-of-the-box, everything is well oiled and well integrated.
so, yeah, imho django is an amazing backend framework that does its job perfectly, specially when you add some really good libraries (like django-rest-framework).
every time i start a project with something other than django, i end up with django, but "homebrewed".
example: you start with flask. you need auth, so you add flask-login.
you need some database access, so you add SQLAlchemy (and its flask plugin). you also need some kind of admin page, so you add flask-admin.
when you are finished, you have a flask-django framework, but not as well integrated -- with django, you get ALL of those all of those out-of-the-box, everything is well oiled and well integrated.
so, yeah, imho django is an amazing backend framework that does its job perfectly, specially when you add some really good libraries (like django-rest-framework).
Same, I do a lot of starlette/sqlqlchemy/etc. and I often miss Django and it’s batteries included approach. Django has its warts but my god is it productive.
Every time I read a new comment about webapp stuff, new languages and "technologies" seem to be mentioned.
How does anybody keep up with this stuff, let alone create it all? :p
How does anybody keep up with this stuff, let alone create it all? :p
Lol yes this is what I am trying to run away from ironically! Forget Elm and HTMX for a second: I would like to use Django because it should be boring tech to get the job done. HTMX allows you to have interaction without JS using HTML-like primitives. I would just learn what I need. Elm is something I used before but not really needed! More of an indulgence. Vanilla JS will do though. No need for Elm or React for side projects.
I am trying to avoid the nextjs/react/ etc stuff where I spend half my time on tooling issues. JS itself is nightmarish (people complain about python dependencies but I haven’t yet seen a big issue yet) but node JS weird module errors and myriad places things are configured and that you usually have build steps etc. Makes me want to get away from that.
You don’t need to “keep up”. You don’t need to know all 100 ways to make a sausage. Just make sausages. Occasionally tweak the machine.
I am trying to avoid the nextjs/react/ etc stuff where I spend half my time on tooling issues. JS itself is nightmarish (people complain about python dependencies but I haven’t yet seen a big issue yet) but node JS weird module errors and myriad places things are configured and that you usually have build steps etc. Makes me want to get away from that.
You don’t need to “keep up”. You don’t need to know all 100 ways to make a sausage. Just make sausages. Occasionally tweak the machine.
We use the Django Admin A LOT. It's an amazing power. Lately, we've also added a Jupyter server connected to a read-only DB replica, with the Django models available.
It's impressive how much you can do with these two tools. There's no need for an internal management dashboard or a BI tool. Just the admin and a bunch of notebooks.
(Obligatory note: we are a bootstrapped startup)
It's impressive how much you can do with these two tools. There's no need for an internal management dashboard or a BI tool. Just the admin and a bunch of notebooks.
(Obligatory note: we are a bootstrapped startup)
I’ve found htmx to be the ultimate Django customising machine. Just make an htmx view and stick it anywhere in your admin. You can do this either by overriding a specific model admin’s template for more complex logic (for example the change template), or by sticking the htmx view in an admin read only field (super simple and works very well).
This approach allows you to have some very complex views in the Django admin without ever touching the internal of the Django admin itself. I used to waste hours trying to get the admin to do what I wanted until I figured out this neat little trick.
This approach allows you to have some very complex views in the Django admin without ever touching the internal of the Django admin itself. I used to waste hours trying to get the admin to do what I wanted until I figured out this neat little trick.
Just want to chime in and say I've been using AppLiku to host a Django service since over a year and it's a great alternative to Heroku if one is bogged down by the limitations. Kudos to the maker!
Thanks! Super happy to hear that it keeps being valuable and useful for you! Keep deploying
Thanks for the awesome and super affordable service. It's truly a saviour for me.
Deploys from today: https://imgur.com/a/3h7yYlO
Deploys from today: https://imgur.com/a/3h7yYlO
django admin > database console.
Even though the admin is far from perfect it is a fantastic alternative to having operations people have to contend wit a database control panel.
Even though the admin is far from perfect it is a fantastic alternative to having operations people have to contend wit a database control panel.
Yes absolutely.
Ops people love spreadsheets and it is done in admin easily.
Also, with Admin site you can limit their ability to screw things up massively.
The amount of stress and time waste you remove by giving them pretty user friendly admin with such low effort is astonishing.
Also, with Admin site you can limit their ability to screw things up massively.
The amount of stress and time waste you remove by giving them pretty user friendly admin with such low effort is astonishing.
However, I also dislike so much of it. The hacks I have used to contort it to do what I want I would be embarrassed for another developer to see...
Former Django fellow Carlton is working on a nice toolkit called "Neapolitan", it's early stage, but is designed to enable building CRUD views very quickly. There is a good chance that in time it, or a layer on top of it, will become the perfect successor to the Admin.
https://github.com/carltongibson/neapolitan