> As customisable as it can be, I find the problem to be it is
a data-centric view of your system, closely tied to the database models.
You're correct that a truly 'task-centric' UI would be a lot of effort -
but really - how common are such interfaces in their fullest sense? In
reality nearly every admin UI is a fairly clear mirror of the underlying
data schema. Show me a web app and I've got a fairly good chance of
predicting the db tables.
I suspect that what is much more common is the ability to have
'cross-cutting concerns' - i.e. actions that involved and orchestrate
changes over multiple tables. There are many places that you can enable
such things without needing to twist the admin too far out of shape:
usertools, admin actions, custom changelist columns etc etc.
I'm not claiming any of this results in the 'perfect ui' and given the
budget - yes - a ground-up custom admin would probably be superior. But
real-life projects are nearly always budget constrained - especially away
from the public-facing side - and quite frankly - the Django admin has
enabled me to complete projects that would have been financially impossible
to develop without it.
> Perhaps a better way to think of it as the difference between
a "management" and a "maintenance" interface.
I'm not sure I am clear on the distinction you are making here.
> True, in a lot of cases these can be the same thing, and for
simpler sites Admin works "just fine". However, I've been on too many
projects that wind up spending a lot of time and effort customising Admin
to do things that would have been simpler in a custom view.
This comes back to my point that it's not a binary choice. The
admin+customization gets you 80% of the way there quickly. When you find
something that doesn't fit nicely just add a line to urls.py and a {%
extends "admin/base_site.html" %} to the top of your template and you've
got the full power of Django to solve that one particular piece of the
problem.
> Is it possible to add other views to admin? Sure... though it's
not clear, or well documented.
I would argue that it's also fairly clear as it's mostly "just django". At
its simplest an admin view is just a Django view that uses the admin base
template. What's unclear about that? How to incorporate linkage between the
admin-proper and custom views is fairly simple but maybe not immediately
obvious to a beginner. The various hooks for this are fairly well
documented although the documentation is scattered through various places
on this rather monolithic
page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/
A single 'common ways to customize the admin' page could go a long way to
helping here.
On Thursday, 11 February 2016 01:33:03 UTC, Curtis Maloney wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote:
> > I can't help but feel that the "admin is very rudimentary and hard to
> > customize" is perpetually overplayed by many in the community. Maybe I'm
> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
>
> I must admit I'm a large proponent of warning against getting caught up
> in "Admin as my management console".
>
> As customisable as it can be, I find the problem to be it is a
> data-centric view of your system, closely tied to the database models.
>
> IMHO a management interface for site should be a _process_ centric view,
> abstracting away the implementation details of tables and fields.
>
> Perhaps a better way to think of it as the difference between a
> "management" and a "maintenance" interface.
>
> True, in a lot of cases these can be the same thing, and for simpler
> sites Admin works "just fine". However, I've been on too many projects
> that wind up spending a lot of time and effort customising Admin to do
> things that would have been simpler in a custom view.
>
> Worse still, I've seen projects alter their schema design to accommodate
> Admin's limitations [like lack of nested inlines]
>
> Is it possible to add other views to admin? Sure... though it's not
> clear, or well documented.
>
> Can documentation alone overcome this problem? I'm not convinced it can.
>
> For some years now I've been proposing an investigation into slicing
> Admin into two layers: a base "management interface framework" layer,
> and "admin" built atop this framework.
>
> Then we can keep providing the Admin we all know and love, and also make
> it easier for people to build their own management interfaces.
>
> However, I don't currently have the time [or admin familiarity] to
> undertake this work.
>
> --
> Curtis
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/cd421287-c2af-41b1-b089-54ba086ab4ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
