Estoy empezando a usar Django para un proyecto personal.aplicación Django Admin o rodar la mía?
¿Cuáles son los pros y los contras de utilizar la aplicación de administración integrada frente a la integración de mis funciones administrativas en la propia aplicación (al marcar request.user.is_staff)?
Este es un wiki de la comunidad porque podría considerarse una encuesta.
Realmente depende del proyecto, supongo. Si bien puedes hacer todo en el administrador, cuando tu aplicación se vuelve más compleja, el uso del administrador también se vuelve más complejo. Y si desea que su aplicación sea realmente fácil de administrar, quiere controlar cada pequeño detalle, lo cual no es posible con la aplicación de administración.
Creo que se debe ver así:
Usando administración de Django: ahorrar tiempo de escribirlo, perder el tiempo de usarla.
Rolling your own admin: pierda tiempo escribiendo, ahorre tiempo utilizándolo.
Probablemente pase el tiempo rodando mi propio administrador, entonces. – Powerlord
-1: No es una simple compensación. El 80% de lo que necesita está integrado. Menos del 20% debe construirse a mano. –
-1: No hay razón para perder tiempo rodando su propio reemplazo hasta que sepa que vale la pena el tiempo. –
Usaría la aplicación de administración de Django, por una serie de razones. Primero, escribir una aplicación de administración puede ser bastante complicado y tomarse un tiempo si quieres hacerlo bien, y django.contrib.admin es gratis y funciona de la caja. 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 tiempo en reescribirlo hasta que esté realmente seguro de que no puede hacerlo. 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 pan comido.
+1: para algunas transacciones clave, puede hacer las suyas propias. Para la mayoría de las transacciones, use lo que está incorporado. –
Me parece triste que, si bien la aplicación de administración django ahorra mucho tiempo al principio, se convierte en una molestia más adelante, ya que su clientela exige más funciones que no se integran fácilmente con la interfaz de administración predeterminada. Puede terminar con dos tipos de herramientas de administración: el administrador de django (para aplicaciones que requieren una simple entrada de datos) y su interfaz de administración personalizada para otras aplicaciones que requieren una interfaz más completa.
Es muy fácil anular selectivamente partes del administrador en diversos grados.
Puede:
plantillas de anulación de administrador en una aplicación de base de aplicaciones o incluso el modelo de base del modelo.
vistas Anulación de administración de heredar y subclases
captura la URL de administración para poner el suyo antes de que en urls.py y proporcionar sus propias interfaces que se basan en administrador apariencia
. ..y mucho más.
Así que comience con la administración y luego inserte la funcionalidad personalizada que necesite donde la necesite.
Hay un montón de aplicaciones que hacen cosas inteligentes con el administrador. Por ejemplo:
También busque django-snippets para los snippets relacionados con el administrador y this page tiene una gran cantidad de información.
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 interesantes, y su obra se muestra lo fácil que es: http://jannisleidel.com/2008/11/wysiwym-editor-widget-django-admin-interface/
Un proyecto que estoy trabajando en recientemente incorporado un selector de tiempo que utiliza 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 las almacenaría en la base de datos como un datautil.rruleset en escabeche. Luego, solo da sugerencias de administración sobre qué widgets usar para los diversos campos.
Se trata de definir su clase de datos, su propio widget que subclasifica formularios. Widget, su propio campo que forma subclases. Campo y 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 vuelta a través de esos dos pasos. Es realmente una cosa de belleza.
Los campos que cree serán una de las propiedades intelectuales más reutilizables y sofisticadas que pueda acumular ... y no tiene que escribir su propio administrador desde cero.
Creo que esta es la respuesta más constructiva para esta pregunta. No he pensado en usar el administrador de Django únicamente para una aplicación web. Pero, supongo que se puede hacer. – swdev
Recomiendo habilitar el sitio de administración en casi todo tipo de proyecto. El costo de configurarlo 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 unidireccional, del webmaster a los visitantes, entonces el sitio de administración es probablemente todo lo que necesita.
Si, no obstante, su sitio tiene una interacción más rica entre sus usuarios, deberá compilar las vistas de django que pueden habilitar esa interacción y al mismo tiempo limitar el acceso a lo que los usuarios realmente pueden hacer.
Me gustaría ir con la funcionalidad de administración de Django, antes de escribir la suya. 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 tomado 4 veces más tiempo para hacerlo. Simplemente no puedo ver un escenario donde quieras escribir el tuyo.
Estoy picando (el TypeError que obtendrías sería bastante informativo), pero quieres usar 'request.user.is_staff' - sin parens. Es un atributo, no un método. – AdamKG
Lo siento, fuerza de hábito. Trabajo como Desarrollador Java, donde siempre usas getters y setters por razones de encapsulación. – Powerlord