Application Django pouvant fournir une fonctionnalité de téléchargement de fichiers multiple / en masse conviviale vers d'autres applications

Question

Je vais être honnête: c’est une question que j’ai posée sur la liste de diffusion Django-Users de la semaine dernière. Comme je n’ai pas encore reçu de réponse, je le republie sur Stack Overflow dans l’espoir que cela suscite davantage d’attention ici.

Je souhaite créer une application facilitant la convivialité, téléchargement de fichiers multiples / en masse dans vos propres applications. Avec convivial, je signifie l'envoi comme Gmail, Flickr, ... où l'utilisateur peut sélectionner plusieurs fichiers à la fois dans la boîte de dialogue Parcourir le fichier. Les fichiers sont ensuite téléchargés séquentiellement ou en parallèle et un bon aperçu des fichiers sélectionnés s'affiche sur la page avec une barre de progression à côté d'eux. Un 'annuler' Le bouton de téléchargement est également une option possible.

Toute cette gentillesse est généralement résolue en utilisant un objet Flash. Achevée des solutions existent pour le côté client, comme par exemple: SWFUpload http://swfupload.org/ , FancyUpload http://digitarald.de/project/fancyupload/ , Téléchargeur YUI 2 http://developer.yahoo.com/yui/uploader/ et probablement beaucoup plus.

Bien sûr, l’astuce consiste à intégrer ces solutions dans votre projet. Surtout dans un framework comme Django, doublez donc si vous voulez qu'il soit réutilisable.

Donc, j'ai quelques idées, mais je ne suis ni un expert sur Django ni sur Solutions de téléchargement basées sur Flash. Je vais partager mes idées ici dans l'espoir de obtenir des commentaires de personnes plus compétentes et expérimentées. (Ou même quelques réponses "Je veux ça aussi!" Répond :))

Vous remarquerez que je fais quelques hypothèses: il s’agit de garder le périmètre (initial) de l'application sous contrôle. Ces hypothèses sont bien sûr discutables:

D'accord, mon idée est pour l'instant:

• Si vous voulez télécharger plusieurs fichiers en masse, vous allez avoir un modèle pour contenir chaque fichier. le modèle contiendra un FileField ou un ImageField. Modèles avec une quantité multiple (mais bien sûr finie) de FileFields / ImageFields n’a pas besoin de charger en masse facilement à l’imho: si vous avez un modèle avec 100 FileFields vous faites quelque chose de mal :) Exemples où vous souhaiteriez utiliser mon type de téléchargement en masse envisagé:

  • Une application qui contient un seul modèle "Brochure" avec un champ de fichier, un champ title (créé dynamiquement à partir du nom de fichier) et une date_added champ.
  • Une application de galerie de photos avec les modèles "Galerie" et "Photo". Vous choisissez un Galerie pour ajouter des images, télécharger les images et les nouveaux objets Photo sont créées et les clés étrangères sont définies dans la galerie choisie.

• Il serait bien de pouvoir configurer ou étendre l'application pour votre solution de téléchargement Flash préférée. Nous pouvons choisir l’un des trois précédents par défaut, mais implémentez l'application pour que les gens puissent facilement ajouter implémentations supplémentaires (un peu comme Django peut utiliser plusieurs bases de données). Laissez-le être agnostique à toute solution côté client particulière.

• Si nous devons en choisir un pour commencer, choisissez peut-être celui avec le plus petite empreinte? (plus petit téléchargement de contenu côté client)

• Les solutions Flash de manière asynchrone (et séquentiellement ou en parallèle) POST les fichiers à une URL. Je suggère que l'URL soit locale vers notre application générique (il en va de même pour chaque application où vous utilisez notre app dans). Cette URL ira à une vue fournie par notre application générique.

• La vue procédera comme suit: créez une nouvelle instance de modèle, ajoutez le fichier, OPTIONNELLEMENT EXTRA STUFF et enregistrer l'instance.

• DO STRAFF EXTRA est le code que l'application qui utilise notre application veut exécuter. Il ne doit pas fournir de code supplémentaire, si le modèle a juste un FileField / ImageField le code de vue standard fera le travail. Mais la plupart des applications voudront faire des choses supplémentaires à mon avis, comme remplir les autres champs: title, date_added, foreignkeys, manytomany, ...

• Je n'ai pas encore pensé à un mécanisme pour DO EXTRA STUFF. Juste envelopper la vue générique de l'application est venu à l'esprit, mais ce n'est pas développeur amicalement, puisque vous auriez à écrire votre propre modèle d’URL et votre propre vue. Ensuite, vous devez dire aux solutions Flash d'utiliser une nouvelle URL etc... Je pense que quelque chose comme des signaux pourrait être utilisé ici?

• Forms / Admin: Je suis encore très flou sur la meilleure façon de réaliser tout cela. intégré dans les formulaires / widgets / admin Django génériques ou admin ... (et c’est là que mon manque d’expérience Django montre):

  • Dans le cas de l'application Galerie / Photo: Vous pouvez fournir un widget d'envoi de photos en masse dans les détails de la galerie. forme. Mais que se passe-t-il si l'instance de Gallery n'est pas encore enregistrée? Le fichier La vue de téléchargement ne pourra pas définir les clés étrangères sur la photo. les instances. Je vois que l'application auth, quand vous créez un utilisateur, demande d'abord pour le nom d'utilisateur et mot de passe et alors seulement vous fournit un plus grand formulaire pour remplir les adresses e-mail, choisir les rôles, etc. Nous pourrions faire quelque chose comme: ça.
  • Dans le cas d'une application avec un seul modèle: Comment fournissez-vous un formulaire dans l'administrateur Django pour faire votre masse télécharger? Vous ne pouvez pas le faire avec le formulaire de détail de votre modèle, c'est juste pour une instance de modèle.

Il y a probablement des dizaines de questions supplémentaires auxquelles il faut répondre avant Je peux même commencer sur cette application. Alors s'il vous plaît dites-moi ce que vous pensez! Donner moi entrée! Qu'est-ce que tu aimes? Quoi pas? Que feriez-vous différemment? Est cette idée solide? Où est-ce pas?

Merci!

Answer 1

Je viens de publier une application simple il y a environ un mois: django-uploadify .

Il s’agit en fait d’une balise de modèle Django servant de wrapper pour le très astucieux Uploadify (nécessite jQuery). L’utiliser est aussi simple que de l’ajouter à votre modèle ...

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

La balise déclenchera des événements (1 par fichier) à la fois côté client et côté serveur (signal Django) pour indiquer quand un fichier entrant a été reçu.

Par exemple, si vous avez un modèle "Media" qui gère tous les fichiers téléchargés par l'utilisateur ...

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

Consultez le wiki pour savoir comment le configurer et créer le signal. gestionnaires (client / serveur).

À propos de votre implémentation conceptuelle, voici quelques points à prendre en compte:

• L’application crée automatiquement le " Modèle de fichier " l'instance n'est probablement pas aussi robuste que les gens peuvent déjà avoir leurs propres modèles avec lesquels ils travaillent
• Si vous souhaitez implémenter n'importe quel type de sécurité ou d'authentification, vous avez besoin d'un système ouvert et d'un type moins «de création automatique»
• Je pense vraiment que les signaux / événements sont le moyen de gérer cela, mais également la partie "Faites-en d'autres choses" de ce que vous avez mentionné.
• Ma conclusion a été que le téléchargement multiple ne peut jamais être un widget de formulaire dans le sens où Django implémente des widgets de formulaire. 1 fichier sera probablement représenté par 1 instance de modèle (à quelques exceptions près), ce qui signifie que nous nous retrouvons dans une situation où 1 widget peut représenter N instances de modèle. Cependant, Django est configuré pour qu'un widget représente 1 valeur pour 1 champ dans 1 instance. Cela ne convient tout simplement pas à la majorité des cas d'utilisation de l'avoir comme widget (d'où la raison pour laquelle j'ai choisi la route des balises template).