Admin "App" Generator?

Hello all!

TL;DR: Any appetite to add/has anyone made a makemigrations-like management command that takes your current admin setup and recreates it with all the URLConfs, Views, Forms, Formsets, Templates, etc. that you need to recreate what you’ve already built in your admin classes so you can easily move from using the admin classes to full custom views when your system grows beyond the level of complexity that the admin system was designed for?

Background/Motivation:
Recently I was looking around for a way customize an admin page (which I found a good plugin to do what I wanted), but along the way I came across many conversations that are basically someone asking for some feature to be added into the admin panel to support some use case and basically being told that they shouldn’t be using the admin for that purpose and to build their own views. While I personally disagree with that as basically a default answer for if something can be added to the admin, that’s not what this post is about.

What kind of things am I talking about here?

Things that to me at least seem like half-finished/missing functionallity that makes total sense with everything else. Like, this specific example was about why there isn’t a way to get a button on an object’s detail page that triggers a custom action. Instead you must go to the list view, search for the object, click the checkbox, change the dropdown at the top, and then click go. That’s like 6 clicks for something that could be 1. You wouldn’t even need to change the admin action in any way to support it, just pass in a queryset of the single object. But I digress, I ended up finding django-object-actions · PyPI which does this but it’s frustrating to need to install a library (whose support is likely not on par with Django’s in terms of security or reliability) to do something that (to me at least) really feels like it should have been supported from the beginning of that feature. At least for a “batteries included” type project like Django. And this is certainly not the first time I’ve found I need to install a library to something pretty basic like this.

Instead, it got me thinking about why it frustrated me so much every time I read that same answer over and over and I eventually realized it’s because if you’ve spent time customizing the admin panel to work well for your basic needs but then outgrow that, there’s no easy way to take what you’ve “already build” in the admin system and move it into full Django views/templates/etc. that you can then customize to your hearts content. There’s also not a great way that I’ve found yet to bridge the gap between using the admin panel for basic editing and building out custom workflows and such. These things usually (at least for me) happen incrementally where you add a boolean here, a list filter there, a custom action way over yonder, etc. and then you come across something that you’re like “ah, this isn’t a good fit for the admin system” but by now you’ve built up a lot of stuff that already works in the admin system (that can sometimes be impressively complex!) and it takes a lot of mental effort to “throw that out” and recreate it from scratch.

“Proposal”/idea:
So, what I’m throwing out into the ether to see if there’s some appetite for is basically some form of “off ramp” for people to use what they’ve already built/customized for the admin panel but bring it out of the admin app and into their own application. I could see this taking a few forms such as:

  • A makemigrations-like command that analizes what you’ve already built in the admin and builds you all the Views, URLConfs, Forms, Formsets, etc. (for brevity I’ll call these the “admin tools” collectively) necessary to effectively recreate that.
  • Making the admin tools more directly usable outside of customizing the Admin classes (which, I’m assuming was kinda the original intention of the List, Create, etc. views, but the admin versions are wayyy more powerful and full-featured than those) to allow people to do basically the same thing as above themselves.
  • Hooks into the admin system that let you replace specific pages with your own custom versions but still generally work with the rest of the admin (such as supporting FK’s across them, etc.)
  • Something else?

To be clear I don’t have a specific proposal to put forward here, more just an idea that I’m curious if there’s been attempts at before and/or an appetite to explore as a “new thing” to increase the usefulness of the admin system (which, at least for me has been one of the major attractions of Django and lets us all develop useful systems quickly but then we become victims of our own success) without actually adding (hopefully!) to the complexity of the already-existing stuff.

Thoughts?

1 Like

I don’t think this is very feasible. The first reason being that the table view of the admin is not a reusable component. You’d have to refactor that out first. And I think you’d be stuck refactoring for years after that honestly. There’s no system to plug in your own look-and-feel, django forms are too cumbersome to use programmatically, composing parts is error prone and hard, and the list goes on.

If you want to get to that same resulting end-point though, you can check out iommi where this type of thing is trivial and it’s designed for this kind of usecase already. Of course, that has the downside of starting over with the admin conf as the iommi admin is quite different. I’m one of the authors of iommi so I know this pain well.

Thanks for the thoughts!

Could you expand on what you mean by the following things:

I think you’d be stuck refactoring for years after that honestly

What else do you see as being big/difficult things to refactor out to be usable outside the admin system? I haven’t dug into the code much, but from a conceptual level the admin pages just seem like Forms that have a template that goes with them (at least the detail view). The table would likely be a bit of a challenge given how many ways you can customize it, but I think even something that didn’t handle all the extreme edge cases could be useful; especially if the universal guidance became “migrate to your own view” much faster before that level of complexity could set in.

django forms are too cumbersome to use programmatically

Are there specific impediments you see here/things the admin has done differently than “normal” Forms?

composing parts is error prone and hard

What do you see as needing to be composed? Obviously the overall template, for sure, but I’m not personally seeing much more than that atm.

Cool project with iommi! I haven’t heard about that before; I’ll keep it in the back of my head for when I need something like that.

I don’t know of any such tool but…

A few years back, I (co-)wrote and still maintain DRF Schema Adapter and Associated EmberJS libraries(now unmaintained) to do just that.

So, part of the project was to be 80% compatible with the admin (using similar properties, terms and registration method so no need for big urlconf, etc). Migration from the admin to that setup can be fairly straightforward depending on how customized your admin is (change import for register and update your admin classes to inherit from Endpoint instead of ModelAdmin and one could write a script to do just that)

This is heavily based DRF though as the name implies.

I’m currently (slowly) working on a set of tools to port the concept to vanilla-ish django class-based views.
It is indeed not a small task and I’m not expecting to be able to have anything close to a beta before the second half of 2025 but… if you have the patience, I’d be more than happy to get feedback and suggestions from people who have done exactly what you’re talking about here (grown out of the admin).

Djang-Admin2 also had similar goals but is fortunately not supporting newer versions of Django. I guess it could still be used as a base for such a tool with a bit of grease and love.

The django admin is over 30k lines. The config/hooks are ad hoc and not really thought out in a coherent way. That’s the consequence of the backwards compatibility guarantees and no plan to expand the scope like you say.

The admin we built was only possible because we had spent ~10 years building foundational parts that could then easily be combined into a coherent whole. That work has not been done for the tables in the admin (and not in django-tables2 or django forms in my opinion).

For such a system to be any good, it would need a similar investment and a willingness to break compatibility.