Version 7 (modified by mjumbewu@…, 12 years ago) ( diff )

Link to latest version of django-admin-tools on PyPI

Admin revamp project.

What we propose here is a revamp of the the admin app looking for minimal work to customize the admin, striving for reusability and maintenability while still making it possible to:

  • extend every pages of the admin in an arbitrary fashion without having to rely on Javascript hacks
  • make it possible to add views easily
  • Refresh the design and make it responsive

Current admin limitations

Current methods to customize the pages of the admin are the following:

  • most common way: Override ModelAdmin or Admin class methods, inject needed variables in template context and then override the templates: this can be made simpler, overriding templates is not considered future proof and can be made simpler
  • There are hooks to insert custom code (filter spec, admin actions) but it's predefined, not flexible and bound to features already defined in the admin. What if one wants a custom sidebar that fills the form dynamically from generated list of templates ?
  • Insert Javascript, this is the most flexible way to extend the admin, it's hacky and promotes creation of code that might not be accessible.
  • Overrindg templates: this is tricky since and has the same limitations as above lake of maintenability, readability and reusability and can make an extensive (anti-pattern) use of templatetags to get things done.
  • Monkeypatching: I have no example of that but I know it's used in production on some sites
  • In a context where you have several admin sites or experiences because of different user permissions or settings, templates are the only reusable part. You can create functions to encapsulate some functionality but there is no canvas for that and can become a bit messy with a big file named like admin_views_utils.py.
  • ...

Usecases

  • Create a dashboard
  • Manipulate objects which are not model instances (django-roa django-sneak, django-admin-commands)
  • Read-only objects
  • Going beyond what is offered by current ModelAdmin in terms of form layout/experience (django-admin-tabs)
  • Customize user experience based on cookie
  • Target other devices (django-mobileadmin, maybe something more up-to-date ?)
  • Integrate frontend features/experience in the backend
  • Add links to other views in the admin index page

Bugs, Feature requests

Trac query

Features

High:

  • Same features as current admin
  • Responsive
  • Use class-based-views throughout
  • Clear patterns to extend the admin
  • ...

Low:

  • Reusable components across projects and within the same project
  • ...

Spotlight of current feature of the admin:

  • The new admin app should, like the current admin app, allow the user to enable full secure (permission-based) CRUD in one line of code.

Examples of Admin Extension in the Wild

In alphabetical order:

Built on top of admin-tools:

Simple Bootstrap Themes:

Pros

  • No more hacks: Offers a clear canvas to extend the admin
  • ...

Cons

  • Backward incompatible
  • ...

Comments

  • Instead of proposing a specific solution, let's focus on identifying the issues that the current admin has without the editorial content. For example "no more monkey patching" as a pro without an actual example of functionality that can not be done without monkey patching the admin is baseless. –Travis Swicegood
    • I reworked the page to try to make it more obvious that it's not Hydro the next admin and main topic but that the Hydro application is just an idea with code. –Amirouche
  • A refresh of the UI can be done in a separate project and land in master sooner, I think, same goes for improving current javascript facility. –Amirouche
  • If I may add an item to the wishlist: I need the new admin to be integratable into site's main design. That would mean asset management for the admin, namespacing etc. -pronik
    • What do you mean by «namespacing» ? Isn't the remaining problems not css related ? –Amirouche
      • At $WORK I've integrated admin into our design rather successfully, but the amount of workarounds is gigantic. One thing I needed to do to make this stuff possible without copying files around (merging is a pain) was a LESS stylesheet which included the original admin.css and wrapped it into an #admin selector. There are many other small and not so small problems: e.g. it's not possible to move all JavaScript to the bottom of the page, since somewhere there is inline JavaScript snippet referencing something from the included files. It would be nice if making admin embeddable into site's design were considered from the start. -pronik
Note: See TracWiki for help on using the wiki.
Back to Top