¿Django Admin o la aplicación de mi rollo?

Estoy empezando a usar Django para un proyecto personal.

¿Cuáles son los pros y los contras de usar la aplicación Admin incorporada en comparación con la integración de mis funciones administrativas en la aplicación misma (al verificar request.user.is_staff)?

Esta es una wiki de la comunidad porque podría considerarse una encuesta.

Realmente depende del proyecto, supongo. Si bien puede hacer todo en el administrador, cuando su aplicación se vuelve más compleja, el administrador también se vuelve más complejo. Y si desea que su aplicación sea realmente fácil de administrar, desea controlar cada pequeño detalle, lo que no es realmente posible con la aplicación de administración.

Supongo que deberías verlo así:

Usando django admin: ahorre tiempo escribiéndolo, pierda tiempo usándolo.
Rodando su propio administrador: pierda tiempo escribiéndolo, ahorre tiempo usándolo.

Usaría la aplicación de administración de Django, por varias razones. Primero, escribir una aplicación de administración puede ser bastante complicado y tomar algún tiempo si quieres hacerlo bien, y django.contrib.admin es gratis y funciona de manera django.contrib.admin . En segundo lugar, está muy bien diseñado y es muy agradable trabajar con él (incluso para usuarios no técnicos). En tercer lugar, cubre muchos de los casos comunes y no parece prudente perder el tiempo en volver a escribirlos hasta que esté realmente seguro de que no puede hacer lo contrario. En cuarto lugar, no es realmente tan difícil de personalizar. Por ejemplo, agregar los botones akismet mark-as-spam y mark-as-ham fue realmente un pedazo de pastel.

Es muy fácil anular selectivamente partes del administrador en diversos grados.

Usted puede:

  1. Omitir plantillas de administración en una aplicación por aplicación o incluso modelo por modelo.

  2. Reemplace las vistas de administrador heredando y subclasificando

  3. Capture las direcciones URL de administrador colocando la suya antes en urls.py y proporcione sus propias interfaces basadas en la apariencia de la administración.

… y mucho más.

Así que comience con el administrador y luego ingrese la funcionalidad personalizada que necesite donde la necesite.

Hay un montón de aplicaciones que hacen cosas inteligentes con el administrador. Por ejemplo:

  • django-reversion asume el registro de administración y lo extiende al historial completo.
  • Tusk CMS combina la aplicación django-mptt con el widget clasificable nested de JQuery de una manera ordenada.

También busque django-snippets para obtener fragmentos relacionados con la administración y esta página tiene una gran cantidad de información.

Lamentablemente, al mismo tiempo que la aplicación de administración de django ahorra mucho tiempo al principio, se convierte en un obstáculo más adelante, ya que su cliente exige más funciones que no se integran fácilmente con la interfaz de administración predeterminada. Podría terminar con dos tipos de herramientas de administración: el administrador de django (para aplicaciones que requieren una entrada de datos simple), y su interfaz de administrador enrollada personalizada para otras aplicaciones que requieren una interfaz más rica.

Considere usar el administrador de Django, pero con sus propios widgets hechos a mano para campos particulares. Puede crear partes de formulario sofisticadas y decirle al administrador que use su código para las entradas y pantallas de cualquier campo específico, o todos los campos de un tipo.

Jannis ha hecho algunas cosas geniales, y su trabajo muestra lo fácil que es: http://jannisleidel.com/2008/11/wysiwym-editor-widget-django-admin-interface/

Un proyecto en el que estoy trabajando recientemente incorporó un selector de tiempo que usa menús desplegables para las distintas partes del tiempo, (h, m, s) Otro campo indicaría qué días de la semana eran recurrentes … usaría 7 casillas de verificación para los días de la semana, y guárdelo en la base de datos como dateutil.rruleset pickled. Luego, simplemente le da al administrador sugerencias sobre qué widgets usar para los diversos campos.

Se trata de definir su clase de datos, su propio widget, que forma las subclases. El widget, su propio campo, que forma las subclases. Campo y un modelo. Campo también. Cada una de las tres clases es agradable, simple y limpia, y es responsable de una transición de la base de datos al Modelo, del Modelo al Widget, y de nuevo a través de esos dos pasos. Es realmente una cosa de belleza.

Los campos que cree serán parte de la propiedad intelectual más reutilizable y sofisticada que puede acumular … y no tiene que escribir su propio administrador desde cero.

Recomiendo habilitar el sitio de administración en casi todos los tipos de proyectos. El costo de configuración es bastante bajo y le brinda un mecanismo razonablemente conveniente para inspeccionar y modificar su sitio.

Si su sitio tiene principalmente un flujo de información de un solo sentido, desde el webmaster hasta los visitantes, entonces el sitio de administración es probablemente todo lo que necesita.

Sin embargo, si su sitio tiene una interacción más rica entre sus usuarios, tendrá que componer vistas de django que puedan habilitar esa interacción y al mismo tiempo limitar el acceso a lo que realmente pueden hacer los usuarios.

Me gustaría ir con la funcionalidad de administración de Django, sobre escribir la tuya propia. Puede personalizar el administrador de Django agregando sus propias plantillas para el administrador, sus propios widgets, etc. Estoy trabajando en un proyecto con un administrador de Django muy personalizado. Si hubiéramos decidido escribirlo a mano, habría tardado 4 veces más en hacerlo. Simplemente no puedo ver un escenario en el que quieras escribir el tuyo.