App Django in grado di fornire funzionalità di caricamento di file multipli / di massa facili da usare su altre app

Question

Sarò onesto: questa è una domanda che ho posto nella mailing list di Django la scorsa settimana. Dal momento che non ho ancora ricevuto alcuna risposta, la sto ripubblicando su Stack Overflow nella speranza che ottenga più attenzione qui.

Voglio creare un'app che semplifichi la facilità di utilizzo, caricamento di file multipli / di massa nelle tue app. Con facile da usare I significa upload come Gmail, Flickr, ... dove l'utente può selezionare più file contemporaneamente nella finestra di dialogo Sfoglia file. I file vengono quindi caricati in sequenza o in parallelo e una bella panoramica dei file selezionati viene mostrato sulla pagina con una barra di avanzamento accanto a loro. A 'Annulla' anche il pulsante di caricamento è un'opzione possibile.

Tutta quella gentilezza è di solito risolta usando un oggetto Flash. Completare le soluzioni sono disponibili per il lato client, come ad esempio: SWFUpload http://swfupload.org/ , FancyUpload http://digitarald.de/project/fancyupload/ , YUI 2 Uploader http://developer.yahoo.com/yui/uploader/ e probabilmente molti altri.

Ovviamente il trucco sta nel integrare queste soluzioni nel tuo progetto. Soprattutto in un framework come Django, raddoppia quindi se vuoi essere riutilizzabile.

Quindi, ho alcune idee, ma non sono né un esperto di Django né di Soluzioni di upload basate su Flash. Condividerò qui le mie idee nella speranza di ottenere feedback da persone più competenti ed esperte. (O anche solo alcune risposte "Lo voglio anche io!" :))

Noterai che faccio alcune ipotesi: questo è per mantenere il ambito (iniziale) dell'applicazione sotto controllo. Questi presupposti sono ovviamente discutibili:

Va ??bene, la mia idea è finora:

• Se si desidera caricare in massa più file, si avrà un modello in cui contenere ciascun file. Ad es. il modello conterrà uno FileField o un ImageField. Modelli con quantità multiple (ma ovviamente finite) di FileField / Gli ImageField non hanno bisogno di un facile caricamento di massa imho: se ne hai uno modello con 100 FileField stai facendo qualcosa di sbagliato :) Esempi in cui vorresti il ??mio tipo di upload di massa previsto:

  • Un'app che ha un solo modello 'Brochure' con un campo file, a campo del titolo (creato dinamicamente dal nome del file) e un date_added campo.
  • Un'app per la galleria fotografica con i modelli 'Galleria' e 'Foto'. Scegli un Galleria per aggiungere immagini, caricare le immagini e nuovi oggetti fotografici vengono create e le chiavi esterne impostate sulla Galleria selezionata.

• Sarebbe bello poter configurare o estendere l'app per il tuo soluzione di caricamento Flash preferita. Possiamo scegliere uno dei tre sopra come un valore predefinito, ma implementa l'app in modo che le persone possano facilmente aggiungere implementazioni aggiuntive (un po 'come Django può usarne più banche dati). Lascia che sia agnostico a qualsiasi particolare soluzione lato client.

• Se dobbiamo sceglierne uno per cominciare, magari sceglierne uno con minimo ingombro? (il più piccolo download di contenuti lato client)

• Le soluzioni basate su Flash in modo asincrono (e sequenzialmente o in parallelo) POSTARE i file su un URL. Suggerisco che l'URL sia locale alla nostra app generica (quindi è la stessa per ogni app in cui usi la nostra app in). L'URL verrà visualizzato in una vista fornita dalla nostra app generica.

• La vista eseguirà le seguenti operazioni: creare una nuova istanza del modello, aggiungere il file, OPZIONALMENTE FARE STUFF EXTRA e salvare l'istanza.

• DO EXTRA STUFF è il codice che l'app che utilizza la nostra app vuole eseguire. Non è necessario fornire alcun codice aggiuntivo, se il modello ha solo un FileField / ImageField il codice di visualizzazione standard farà il lavoro. Ma la maggior parte delle app vorrà fare cose extra secondo me, come compilare gli altri campi: titolo, date_added, foreignkeys, manytomany, ...

• Non ho y

Answer 1

Ho appena rilasciato una semplice app per questo circa un mese fa: django-uploadify .

È fondamentalmente un tag modello Django che funge da involucro per la molto elegante Uploadify (richiede jQuery). Usarlo è semplice come aggiungere questo al tuo modello ...

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

Il tag genererà eventi (1 per file) sia sul lato client che sul lato server (segnale Django) per indicare quando è stato ricevuto un file in arrivo.

Ad esempio, supponendo che tu abbia un modello "Media" che gestisce tutti i file caricati dall'utente ...

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’)

Dai un'occhiata alla wiki per informazioni su come impostarlo e creare il segnale gestori (client / server).

---

Informazioni sulla tua implementazione concettuale dall'alto, ecco alcuni punti da considerare:

• Se l'app crea automaticamente il " Modello di file " l'istanza probabilmente non è così solida come le persone potrebbero già avere i propri modelli con cui stanno lavorando
• Se si desidera implementare qualsiasi tipo di sicurezza o autenticazione, è necessario un sistema aperto e meno di un tipo di "creazione automatica"
• Penso davvero che segnali / eventi siano il modo per gestirlo, e anche per gestire la parte "FARE ALTRO STUFF" di ciò che hai menzionato.
• La mia conclusione è stata che il caricamento multiplo non può mai essere realmente un widget modulo, nel senso che Django implementa i widget modulo. Molto probabilmente 1 file sarà rappresentato da 1 istanza del modello (con alcune eccezioni), il che significa che finiamo con una situazione in cui 1 widget può rappresentare N istanze del modello. Tuttavia Django è configurato in modo che un widget rappresenti 1 valore per 1 campo in 1 istanza. Semplicemente non si adatta alla maggior parte dei casi d'uso averlo come widget (quindi perché sono andato sul percorso del tag modello).