Aplicación Django que puede proporcionar funciones de carga de archivos múltiples / masivas fáciles de usar a otras aplicaciones

Question

Voy a ser sincero: esta es una pregunta que hice en la lista de correo de Django-Users la semana pasada. Como todavía no recibí ninguna respuesta, la vuelvo a publicar en Stack Overflow con la esperanza de que reciba más atención aquí.

Quiero crear una aplicación que facilite su uso, carga de archivos múltiples / masivos en sus propias aplicaciones. Con usuario amigable I significa subir como Gmail, Flickr, ... donde el usuario puede seleccionar múltiples archivos a la vez en el cuadro de diálogo Examinar archivo. Los archivos se cargan secuencialmente o en paralelo y una buena descripción de los archivos seleccionados se muestra en la página con una barra de progreso junto a ellos. A 'Cancelar' el botón de carga también es una opción posible.

Toda esa simpatía generalmente se resuelve mediante el uso de un objeto Flash. Completar existen soluciones para el lado del cliente, como: SWFUpload http://swfupload.org/ , FancyUpload http://digitarald.de/project/fancyupload/ , YUI 2 Uploader http://developer.yahoo.com/yui/uploader/ y probablemente muchos más.

Por supuesto, el truco consiste en integrar esas soluciones en su proyecto. Especialmente en un marco como Django, doble si quieres para que sea reutilizable.

Entonces, tengo algunas ideas, pero no soy experto en Django ni en Soluciones de carga basadas en flash. Compartiré mis ideas aquí con la esperanza de Obteniendo comentarios de personas con más conocimientos y experiencia. (O incluso algunas respuestas de '¡Yo también quiero esto! :))

Notarás que hago algunas suposiciones: esto es para mantener el Alcance (inicial) de la aplicación bajo control. Estos supuestos son, por supuesto, discutibles:

Muy bien, mi idea es hasta ahora:

• Si desea cargar en masa múltiples archivos, tendrá un modelo para contener cada archivo. I.e. el modelo contendrá uno FileField o un ImageField. Modelos con múltiples (pero por supuesto finitos) cantidad de FileFields / ImageFields no necesita una carga masiva fácil en mi humilde opinión: si tiene un modelo con 100 FileFields estás haciendo algo mal :) Ejemplos en los que desearía mi tipo de carga masiva prevista:

  • Una aplicación que tiene un solo 'Folleto' modelo con un campo de archivo, un campo de título (creado dinámicamente a partir del nombre del archivo) y un date_added campo.
  • Una aplicación de galería de fotos con los modelos 'Galería' y 'Foto'. Tu eliges un Galería para agregar imágenes, cargar las imágenes y nuevos objetos de fotos se crean y las claves externas se configuran en la Galería elegida.

• Sería bueno poder configurar o extender la aplicación para su solución favorita de carga de Flash. Podemos elegir uno de los tres anteriores como predeterminado, pero implemente la aplicación para que las personas puedan agregar fácilmente implementaciones adicionales (como Django puede usar múltiples bases de datos). Deje que sea independiente de cualquier solución particular del lado del cliente.

• Si necesitamos elegir uno para comenzar, tal vez elija el que tenga huella más pequeña? (descarga más pequeña de material del lado del cliente)

• Las soluciones basadas en Flash de forma asíncrona (y de forma secuencial o en paralelo) PUBLICA los archivos en una url. Sugiero que url sea local a nuestra aplicación genérica (por lo que es igual para todas las aplicaciones en las que utiliza nuestro aplicación en). Esa URL irá a una vista proporcionada por nuestra aplicación genérica.

• La vista hará lo siguiente: crear una nueva instancia de modelo, agregar el archivo, OPCIONALMENTE HAGA COSAS ADICIONALES y guarde la instancia.

• DO EXTRA STUFF es un código que la aplicación que usa nuestra aplicación quiere ejecutar. No tiene que proporcionar ningún código adicional, si el modelo solo tiene un FileField / ImageField, el código de vista estándar hará el trabajo. Pero creo que la mayoría de las aplicaciones querrán hacer cosas adicionales, como completar los otros campos: título, fecha_añadida, teclas extranjeras, muchastomanías, ...

• Todavía no he pensado en un mecanismo para DO EXTRA STUFF. Sólo me vino a la mente envolver la vista genérica de la aplicación, pero eso no es desarrollador amigable, ya que tendrías que escribir tu propio patrón de URL y tu vista propia Luego tienes que decirle a las soluciones Flash que usen una nueva url etc ... ¿Creo que algo como las señales podrían usarse aquí?

• Formularios / Administrador: todavía estoy muy incompleto sobre cómo podría ser todo esto mejor integrado en el administrador o formularios genéricos Django / widgets / ... (y esta es mi falta de experiencia en Django):

  • En el caso de la aplicación Galería / Foto: Puede proporcionar un widget de carga masiva de fotos en los detalles de la Galería formar. Pero, ¿qué pasa si la instancia de la Galería aún no se ha guardado? El archivo la vista de carga no podrá establecer las teclas foráneas en la foto instancias. Veo que la aplicación de autenticación, cuando crea un usuario, primero pregunta para nombre de usuario y contraseña y solo entonces le proporciona una formulario para completar correos electrónicos, elegir roles, etc. Podríamos hacer algo como eso.
  • En el caso de una aplicación con un solo modelo: ¿Cómo se proporciona un formulario en el administrador de Django para hacer su masa ¿subir? No puedes hacerlo con la forma detallada de tu modelo, eso es solo para una instancia de modelo.

Probablemente hay docenas más de preguntas que deben responderse antes Incluso puedo comenzar con esta aplicación. ¡Así que por favor dime lo que piensas! Dar me entrada! ¿Qué te gusta? Que no ¿Qué harías diferente? Es esta idea sólida? ¿Dónde no está?

¡Gracias!

Answer 1

Acabo de lanzar una aplicación simple para esto hace aproximadamente un mes: django-uploadify .

Básicamente es una etiqueta de plantilla de Django que actúa como una envoltura para la muy ingeniosa Uploadify (requiere jQuery). Usarlo es tan simple como agregar esto a su plantilla ...

{% load uploadify_tags }{% multi_file_upload ‘/upload/complete/url/’ %}

La etiqueta activará eventos (1 por archivo) tanto en el lado del cliente como en el lado del servidor (señal Django) para indicar cuándo se ha recibido un archivo entrante.

Por ejemplo, suponiendo que tiene un modelo 'Media' que maneja todos los archivos cargados por el usuario ...

def upload_received_handler(sender, data, **kwargs):
    if file:
        new_media = Media.objects.create(
            file = data,
            new_upload = True,
        )
        new_media.save()

upload_recieved.connect(upload_received_handler, dispatch_uid=‘whatever.upload_received’)

Consulte el wiki para obtener información sobre cómo configurarlo y crear la señal manejadores (cliente / servidor).

---

Acerca de su implementación conceptual desde arriba, aquí hay algunos puntos de consideración:

• Hacer que la aplicación cree automáticamente el " Modelo de archivo " Es probable que la instancia no sea tan sólida como la gente ya puede tener sus propios modelos con los que están trabajando
• Si desea implementar cualquier tipo de seguridad o autenticación, necesita un sistema abierto y menos del tipo de "creación automática"
• Realmente creo que las señales / eventos son la forma de manejar esto, y también manejar la parte 'HACER OTRAS COSAS' de lo que mencionó.
• Mi conclusión fue que la carga múltiple nunca puede ser realmente un widget de formulario en el sentido de que Django implementa widgets de formulario. Lo más probable es que 1 archivo esté representado por 1 instancia de modelo (con algunas excepciones), lo que significa que terminamos con una situación en la que 1 widget puede representar N instancias de modelo. Sin embargo, Django está configurado para que un widget represente 1 valor para 1 campo en 1 instancia. Simplemente no es adecuado para la mayoría de los casos de uso tenerlo como un widget (de ahí por qué elegí la ruta de la etiqueta de plantilla).