[mazelife]

I don't know about that. I've customized the heck out of that thing (e.g. https://github.com/mazelife/django-scaffold) and it's quite possible, although you'll need to be pretty familiar with the source code. That said, this particular part of Django is definitely starting to show its age. Compare the look-and-feel and UI with something like ActiveAdmin (http://activeadmin.info/) for Rails and you'll see what I mean. What's more, the approach to "class-based views" feels disconnected to the way Django apps are written now.

[zalew]

> Compare the look-and-feel

http://grappelliproject.com/

[ionelm]

That's horrible to integrate with other django apps that override admin templates or do anything that's not trivial. Reusability => 0.

[mazelife]

Good call; I pretty much always use that for Django projects that need the admin these days. I haven't done an exhaustive side-by-side comparison, but my impression is still that ActiveAdmin provides a more polished user experience.

[sampk]

Those screenshots look good. Try installing it, its even uglier than the default skin.

[zalew]

using it for years, it's ok and clients like it so not sure what's the problem.

[amirouche]

> I don't know about that.

1) (minor) Getting into templates to add an action e.g. «export as CSV» is a lot to ask. (Anything that leads me into changing the templates is, at least for me, a no, except form ergonomy which is in Django regularly done in an API/DSL based on nested dict, list and attributes.)

2) (minor) Custom models (non django.models.Model) or specifiq models (like django scaffold) in the ObjectList aka. ChangeList or in the Form view is not possible which means no mongodb, no kv store, no to anything that hasn't a proper Django's model backend even if in the end it's all about class properties and most of the time slice queries.

3) (major) The admin ergonomy and plugability is poor, you can not choose the way pages feet together, for instance and the primary concern is that the first page must be a list of models regrouped by apps. This is in advanced apps a non sens, most likely when you use a lot of reusable apps, where the code doesn't reflect the end-user experience, the admin will look ugly. But should the admin reflect or map somehow the end-user experience ? It's a complex mapping, the workflow of the admin is elaborate and depends of the app... otherwise said the Django «generated» admin is the equivalent of a spreadsheet compared to specific domain admin areas.

> I've customized the heck out of that thing (e.g. https://github.com/mazelife/django-scaffold)

Does it support filters and actions ? because what it looks like you did is that you are feeting a view to the admin API, leaving the elaborate actions and points of customisation on the side.

> and it's quite possible,

It our job to make things possible.

> although you'll need to be pretty familiar with the source code.

You mean read the code ? It's not that difficult. Also I think django admin reworks bring more clarity.

> That said, this particular part of Django is definitely starting to show its age.

In terms of features or skin ?

> Compare the look-and-feel and UI with something like ActiveAdmin (http://activeadmin.info/) for Rails and you'll see what I mean.

Definetly looks like a customised Django Admin. Also Django Admin already had it's skin war, the feature/API war is barely starting.

> What's more, the approach to "class-based views" feels disconnected to the way Django apps are written now.

What do you mean ?

[mazelife]

I'm not sure I follow all the points you're making. But...

1.) I've created CSV import/export admin functions for models many times and I agree it's a minor customization. I'm not sure why changing templates is a no-go for this or anything else.

2.) To me it seems self-evident that the admin was designed to facilitate model-oriented CRUD operations. The fact that it's hard to integrate non-relational data stores like mongo have nothing to do with the admin, and everything to do with the fact that there is currently no agreed on way to plug NoSQL data stores into Django's ORM. Although this has been is a longstanding point of contention and there was a GSOC project that I think eventually became http://www.allbuttonspressed.com/projects/django-nonrel , my sense is that there just wasn't/isn't enough interest in making this a part of Django core. In other words, this goes well beyond what I would call "admin customization" and get's down to pretty basic questions about what sorts of persistent data stores should be supported by the ORM.

3.) Again, this seems to me to want to be able to stretch the admin beyond what it was designed for. To your point: "the first page must be a list of models regrouped by apps. This is in advanced apps [nonsense], most likely when you use a lot of reusable apps, where the code doesn't reflect the end-user experience, the admin will look ugly. But should the admin reflect or map somehow the end-user experience? It's a 'complex mapping'."

I agree! This is potentially a very complex mapping. While it would be wonderful if there was some way to handle these sorts of things while retaining the easy-to-use, declarative nature of the current ModelAdmin approach, that's a tall order. The right answer at that point might be: build you own admin.

With all props to the current admin, the areas where I see it "starting to show it's age" are skin, user experience, and features. I don't present Rails' ActiveAdmin as a lightyears-ahead-alternative, just an example of an admin that is incrementally better than Django's in those areas I mentioned.

When I say the admin approach to "class-based views" feels disconnected , I mean that while it is technically correct to say that, for example, https://github.com/django/django/blob/master/django/contrib/... is a "class-based" view, it's not a capital-C Class-Based View. In other words, this is an area where features that have been developed in core have not made it back into the admin, even though they could be enormously beneficial and help to make the whole thing more pluggable. That actually seems to be one of the goals of django-admin2, which is great news.

It may be that you and I don't really disagree here all that much. I was responding to the statement of the parent: "try to do anything custom [with the admin] and you're screwed," which I don't think is true. But there are definitions for "custom"--things that go way beyond providing a simple way to model-oriented CRUD operations--that present some real challenges. And frankly, they may go beyond what a general-purpose, easy-to-configure admin can or should do.

(unrelated to my point: the example app of mine I cited does not support filters and actions. It certainly could, if I or someone else had the time to and the need to add it. But it presents some thorny UX problems like "what does it mean to filter out model instances from the list view when the instances are also nodes of a tree? Where do the children go?")