Hacker News Reader

Comment by theptip | Hacker News Reader

My main point of friction in Django is still the admin interface; it's got a very steep sigmoid of a learning curve. The easy stuff is very easy, which is great, but when you want to do something somewhat complex it becomes arcane very quickly, usually requiring step-debugging through the code to figure out which framework method needs to be tweaked.

Also, it's 2017 and we are still selecting ForeignKeys from an unfiltered drop-down menu with potemtially thousands of entries? This is madness. A PR for using select2.js (https://github.com/django/django/pull/6385) has been floating around for a year now, but progress is glacial.

I fear the admin site code has become so flexible and generic that it's difficult to extend, which is discouraging improvements.

Anyone care to shout out their favourite admin site replacements? I've tried a few but not found a great fit.

View on HN

> The easy stuff is very easy, which is great, but when you want to do something somewhat complex it becomes arcane very quickly, usually requiring step-debugging through the code to figure out which framework method needs to be tweaked.

This is the same problem I have with most ORM's as well: the easy stuff is easy, and the hard stuff is harder than just doing your own thing (using SQL directly). My solution to this ORM problem and the admin situation is the same: use admin (and ORM) for doing easy things, and don't use it for hard things. It works well!

I've seen a lot of Django codebases where they try to build the whole app around the admin interface, and it's way more trouble than it's worth. Reasonable people could disagree about this, but my stance is to use it for the easy goodness it provides, but get away from it when it starts getting in the way.

> use admin (and ORM) for doing easy things, and don't use it for hard things. It works well!

With the ORM though there is usually a good reason for why the hard things are hard, and writing your own SQL where needed adds very little friction.

With the admin adding a button to kick off some task should be trivially easy, but for whatever reason involves either using all sorts of terrible hacks that make the codebase completely unreadable, or else creating an entire second admin. That doesn't feel right.

Yeah adding buttons to the top of a detail page, or a second form page for an admin action are unnecessarily hard. I've had to do both a number of times in the last few months, and referring back to an existing implementation is the only way I remember how to do it.

Those two particular customisations should be a lot easier to do, and it might even be something I'll look to implement as a 3rd party library or directly within Django.

It's not the best solution ever, but you might look into raw_id_fields to solve the dropdown issues.

https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#dj...

Yeah this is the best native workaround I'm aware of.

Is it really a workaround, if it's already baked in as a feature though?

Yes, in 2017 it's a workaround. The 2010-onwards way to solve this problem is with a client-side filter in the select input, so that you don't need to open a new window.

I think the Admin is great. Even of you aren't planning to use it in your production app, it makes many development tasks so much easier. It is a great way to create, view and filter your data during development and when you need something new its usually just a line or two of code. It is staring to look a bit dated with the widgets though.

There was a discussion a few years ago about revamping/updating the Django Admin - but I don't think it got much traction:

https://groups.google.com/d/topic/django-developers/Vozu6U3g...

My understanding is it's not something they care enough about yet to fix - or it's too hard/expensive.

UPDATE: Also found this blog post from one of the core devs/founders:

https://jacobian.org/writing/so-you-want-a-new-admin/

> The admin may look simple on the surface, but it’s shockingly complex and represents a ton of work.

This matches my experience. I can't escape the feeling that 90% of that complexity is irrelevant at best, and counterproductive at worst, for my current use-case -- but I haven't quite mustered the bravery to write my own custom admin site for my app.

I wonder if DRF's CoreAPI schemas would make this easier, since you can now auto-generate a JS client for your API models, so you just need to wire up routers and views for your CRUD.

It's not. Every template, every view, every form can be overriden. And all of them have hooks on the admin config class to handle simple customization. The software internal is quite amazing and uses all Django's features in the book.

> uses all Django's features in the book.

Also, I think the admin traditionally has been a good driving force for feature improvement.

IMO, the proper method here is a frog boiling approach. Throwing it out and starting all over is bound to introduce regressions and even new user facing bugs. So we shouldn't of "steady, incremental improvement" as settling. But we could probably use more of those steady incremental improvements.

I personally agree: focus on the most important things, fix those, then move on to the next thing.

I agree that Django's admin interface isn't perfect. However, it's only there to get you started - as you say, it's flexible and generic.

If you have a complicated application then you should be building your own admin interface, with specialised workflows that make it easy for your (admin) users to enter and manipulate the data you wish to manage.

The problem is that it's not really flexible in its default state.

If you want to add a custom action to the instance view of one of your models you have to:

- write a view for your custom action

- override the generated urls for the model admin

- override the template(???) for the admin instance view to show the action

Considering the Admin itself already has the styling in place to add more custom actions, the main issue is that no one has put in place enough infrastructure to make this easier for people.

(Internally we've written a couple helpers for this, though our way of doing thing relies on internal patterns so might not be great for Django itself)

django-extensions is an automatic install for me with the shell_plus feature. They also support an admin FK autocomplete, http://django-extensions.readthedocs.io/en/latest/admin_exte...

At my current place of employment, we modified and extended Django Admin with the Suit[0] theme to become what was basically a CRM that drove the sales and administration of a business with >$1 million revenue.

Eventually we built an actual operations/management/sales interface because Django's admin had too much extra stuff and lacked certain things we wanted to implement, but it wasn't that difficult to put together and it worked well for several months.

[0] http://djangosuit.com/

Similarly, I helped build Student database and CRM for a family of 3 schools totaling ~7M revenue. It's built mostly on top of the admin (with a custom theme).

My experience is that the vast majority of things are out there in the docs, however it does so many things that it takes time to understand it in sufficient depth so as to make significant changes.

The admin is easy; but it's not simple. Behind the simple UI there's a lot of work going on, and a lot of is so that the simple customizations most people work can be done trivially.

Have no shame in making your own templates and views within the admin. That's why it provides those escape hatches.

As soon as you find yourself hacking the admin template to place a button, you should strongly consider ditching the admin interface and rolling your own views.

Django admin is easy to get started with, but a huge pain to extend.

Admin actions work well for many tasks. Or a link styled as a button is easy enough to add, though you will need view to process it.

May be coz it's not meant to be very customizable? When you start overriding methods, it's better to use a regular view.

I've always seen the admin as a sort of phpmyadmin. For doing very basic crud.

You can do some pretty complex stuff with it when you understand how Django''s forms and other parts work.

> I fear the admin site code has become so flexible and generic that it's difficult to extend, which is discouraging improvements.

It's doable. One of the former companies I worked for used to run its entire lead-management-based system on top of a modified 0.96 Django admin, that was ~10 years ago (said company was a mortgage broker). Monkey-patching is a hell of a drug. I'm pretty sure things are way easier to extend now.

Well, it isn't much of a problem, All you need is to use `django-ajax-selects`, and you can make all the fields with foreignKey into ajax loading like select2. If that's your biggest gripe with admin, then here is an easy solution for that.

In Django, you need to explicitly do some things and that's okay.

Admin is an app written in Django. Don't see how evaluating admin app applies to evaluating Django.

I simply add my own admin code separately and add links to the default admin interface to my views.

Reply on news.ycombinator.com