inmemoryuploadedfile - Aplicación Django que puede proporcionar una funcionalidad de carga de archivos múltiples/masivos fácil de usar para otras aplicaciones

upload image django example

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 la carga de archivos múltiples / masivos y fáciles de usar en sus propias aplicaciones. Me refiero a fácil de usar, cargar como Gmail, Flickr, ... donde el usuario puede seleccionar múltiples archivos a la vez en el diálogo de búsqueda de archivos. Los archivos se cargan secuencialmente o en paralelo y se muestra una buena descripción general de los archivos seleccionados en la página con una barra de progreso junto a ellos. Un botón de carga "Cancelar" también es una opción posible.

Toda esa amabilidad generalmente se resuelve usando un objeto Flash. Las soluciones completas están disponibles 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 es conseguir que esas soluciones se integren en su proyecto. Especialmente en un marco como Django, doble así que si quieres que sea reutilizable.

Entonces, tengo algunas ideas, pero no soy un experto en Django ni en soluciones de carga basadas en Flash. Compartiré mis ideas aquí con la esperanza de obtener algunos comentarios de personas con más conocimiento y experiencia. (O incluso solo algunos "¡Yo también quiero esto!" Responde :))

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

Está bien, mi idea es hasta ahora:

• Si desea cargar varios archivos en forma masiva, tendrá un modelo para contener cada archivo. Es decir, el modelo contendrá un FileField o un ImageField. Los modelos con cantidad múltiple (pero por supuesto finita) de FileFields / ImageFields no necesitan una carga masiva fácil: si tienes un modelo con 100 FileFields, estás haciendo algo mal :) Ejemplos donde querrías mi tipo de carga masiva prevista:

  • Una aplicación que tiene solo un modelo ''Folleto'' con un campo de archivo, un campo de título (creado dinámicamente a partir del nombre del archivo) y un campo con fecha_adjudicado.
  • Una aplicación de galería de fotos con modelos ''Galería'' y ''Foto''. Usted elige una Galería para agregar imágenes, cargar las imágenes y se crean nuevos objetos de Foto y se establecen claves foráneas para la Galería elegida.

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

• Si tenemos que elegir uno para empezar, ¿tal vez elegir el que tenga la huella más pequeña? (la menor descarga de material del lado del cliente)

• Las soluciones basadas en Flash de forma asincrónica (y secuencialmente o en paralelo) PUBLICAN los archivos en una url. Sugiero que la URL sea local para nuestra aplicación genérica (por lo que es la misma para cada aplicación en la que use nuestra aplicación). 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 HACER EXTRA STUFF y guardar la instancia.

• DO EXTRA STUFF es un código que la aplicación que utiliza nuestra aplicación desea 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 la mayoría de las aplicaciones querrán hacer cosas extra, creo, como completar los otros campos: title, date_added, foreignkeys, manytomany, ...

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

• Formularios / Administrador: Todavía estoy muy borroso sobre cómo todo esto podría integrarse mejor en el Administrador o en los formularios / widgets genéricos de Django / ... (y esto es lo que muestra mi falta de experiencia en Django):

  • En el caso de la aplicación Galería / Foto: puede proporcionar un widget de carga de fotos en masa en el formulario de detalles de la Galería. Pero, ¿qué pasa si la instancia de la Galería aún no está guardada? La vista de carga de archivos no podrá establecer las claves externas en las instancias de Foto. Veo que la aplicación de autenticación, cuando creas un usuario, primero solicita el nombre de usuario y la contraseña, y solo luego te proporciona un formulario más grande para completar emailadres, elegir roles, etc. Podríamos hacer algo como eso.
  • En el caso de una aplicación con un solo modelo: ¿cómo proporciona un formulario en el administrador de Django para realizar su carga masiva? No puede hacerlo con la forma detallada de su modelo, eso es solo para una instancia de modelo.

Probablemente hay docenas de preguntas más que necesitan respuesta antes de que pueda comenzar en esta aplicación. Entonces por favor dime lo que piensas! Dame entrada! ¿Qué te gusta? Qué 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 un contenedor para el Uploadify muy ingenioso (requiere jQuery). Usarlo es tan simple como agregar esto a tu 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 de 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 la wiki para obtener información sobre cómo configurarlo y crear los manejadores de señal (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 la instancia de "Modelo de archivo" probablemente no sea tan sólida, ya que las personas pueden 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 de un tipo ''autocrear''
• Realmente creo que las señales / eventos son la forma de manejar esto, y también manejar la parte ''HAGA OTRA COSA'' 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 cabe para la mayoría de los casos de uso tenerlo como un widget (de ahí por qué fui la ruta de la etiqueta de la plantilla).