Discussion :

[FirePrawn]

Développez un système d'upload de fichiers et dossiers
similaire à l'explorateur Windows

Grâce aux nouvelles API apparues avec HTML5 il est d'ores et déjà possible de créer un système d'upload de fichiers et de dossiers reprenant le fonctionnement de l'explorateur Windows ou du Finder d'OS X.
Malgré une bonne compatibilité pour la fonction de Drag & Drop, le cas d'un dossier reste problématique.

En effet, lorsqu'un utilisateur veut mettre en ligne un dossier en le faisant glisser à l'endroit prévu, il s'attend à ce que le dossier et tout son contenu (sous-dossiers, fichiers) soient mis en ligne.
Or jusqu'à présent ce n'était pas possible.
L'API HTML5 pour le Drag & Drop ne gère pas les dossiers, et on se retrouve avec un fichier portant le nom du dossier d'une taille nulle.
Ce temps est révolu avec l'arrivée de Chrome 21 !

La dernière version de Chrome apporte en effet une solution pour le transfert d'un dossier via un Drag & Drop.
Dans cette version qui est encore en bêta, une nouvelle méthode fait son apparition sur les objets DataTransferItem qui permet de retourner le dossier que l'on a sélectionné comme une entrée système, et non plus un fichier.
En utilisant l'API file system cette entrée système peut être parcourue avec un simple code javascript :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
 
function traverseFileTree(item, path) {
  path = path || "";
  if (item.isFile) {
    // Get file
    item.file(function(file) {
      console.log("File:", path + file.name);
    });
  } else if (item.isDirectory) {
    // Get folder contents
    var dirReader = item.createReader();
    dirReader.readEntries(function(entries) {
      for (var i=0; i<entries.length; i++) {
        traverseFileTree(entries[i], path + item.name + "/");
      }
    });
  }
}
 
dropArea.addEventListener("drop", function(event) {
  event.preventDefault();
 
  var items = event.dataTransfer.items;
  for (var i=0; i<items.length; i++) {
    // webkitGetAsEntry is where the magic happens
    var item = items[i].webkitGetAsEntry();
    if (item) {
      traverseFileTree(item);
    }
  }
}, false);​

Ce code est disponible sur GitHub : folder_drag_and_drop.js

Pour plus d'informations sur cette nouvelle fonctionnalité, je vous invite à consulter le Wiki correspondant.

Source : Protonet

Et vous ?

Avez-vous déjà essayé de développer un explorateur de dossiers et fichiers se basant sur l'explorateur Windows ?
Attendiez-vous cette évolution de l'API ?

[thelvin]

Hum. Pourquoi pas. Ça aurait pas mal servi à DropBox.

D'habitude je préfère le copy/paste au drag & drop. Surtout sur les systèmes qui gardent un historique des copy récents et évitent de retourner les chercher à chaque fois.

D'un autre côté, fournir un dossier par paste, c'est dangereux. Avec un drag & drop on sait ce qu'on est en train de déplacer, puisqu'on vient de le prendre et on va bientôt le lâcher. Avec un paste, on risque de se tromper et d'oublier qu'on avait copy un dossier qui contient toutes nos coordonnées bancaires.

J'ai du mal à imaginer, à part dropbox et les galeries, quel genre d'applis vont utiliser ça.

[Didlith]

Enfin une solution intéressante passant par un navigateur

... J'ai du mal à imaginer, à part dropbox et les galeries, quel genre d'applis vont utiliser ça ...

Toutes les solutions de gestion documentaire / partage de document (et il y'en a beaucoup). Egalement les gestions de dossiers attachés sur les CRM/ERP par exemple. Les applications ne manquent pas

[CapFlow]

J'ai du mal à imaginer, à part dropbox et les galeries, quel genre d'applis vont utiliser ça.

ça pourrait servir à Wikipedia par exemple, ou même developpez : tu rédiges ta news sur un blocnote ou word, tu le déplaces dans la zone indiquée et tu n'as plus qu'à cliquer sur ok.

[vivoli12]

Oui, enfin là c'est le drag and drop d'un dossier complet (avec sous-dossiers) et pas seulement d'un fichier (ça existe depuis longtemps sur les navigateurs html5).

[thelvin]

ça pourrait servir à Wikipedia par exemple, ou même developpez : tu rédiges ta news sur un blocnote ou word, tu le déplaces dans la zone indiquée et tu n'as plus qu'à cliquer sur ok.

Tu parles de ce qu'il est déjà possible de faire depuis des années ?
Je ne sais pas si Wikipédia ou developpez.net ont jugé utile ou non de s'en servir, mais moi, je le fais depuis un moment.

[ijk-ref]

Ok... mais ça sert toujours à rien et n'apporte aucune nouveauté s'il n'est toujours pas possible... par exemple... de réduire la taille des images efficacement et avant le transfère :-/

[thelvin]

Ok... mais ça sert toujours à rien et n'apporte aucune nouveauté s'il n'est toujours pas possible... par exemple... de réduire la taille des images efficacement et avant le transfère :-/

- C'est vrai que bon, à part réduire la taille des images avant l'upload, on en a un peu rien à foutre des nouveautés web.
- Redimensionner les images est en principe déjà possible avec l'accès en lecture des input file, canvas et son toDataUrl() ou toBlob(), XMLHttpRequest, et beaucoup de courage et de connaissances. Certes quelques tutoriels sur la manière d'utiliser chacun, ne seraient pas du luxe.

[tenpigs]

J'ai raté quelque chose ou cela signifie que n'importe quel site peut lister le contenu de mon disque dur tranquillement et s'uploader des fichiers?

[thelvin]

J'ai raté quelque chose ou cela signifie que n'importe quel site peut lister le contenu de mon disque dur tranquillement et s'uploader des fichiers?

Seulement ce qui se trouve dans un dossier que tu lui aurais fourni en drag & drop. Ce qui est quand même assez sérieux, je trouve, mais bon... Les sites webs deviennent de plus en plus des applications normales, et une application normale n'a pas besoin de ton autorisation pour faire ce qu'elle veut de tes fichiers.

[tenpigs]

Seulement ce qui se trouve dans un dossier que tu lui aurais fourni en drag & drop. Ce qui est quand même assez sérieux, je trouve, mais bon... Les sites webs deviennent de plus en plus des applications normales, et une application normale n'a pas besoin de ton autorisation pour faire ce qu'elle veut de tes fichiers.

Une appli normale tu es censé avoir valider son installation alors qu'une page web, il n'est pas forcément évident de savoir ou tu arrives lorsque tu clic sur un lien dans google...
je crois que je vais arrêter d'utiliser Chrome...

[thelvin]

Une appli normale tu es censé avoir valider son installation alors qu'une page web, il n'est pas forcément évident de savoir ou tu arrives lorsque tu clic sur un lien dans google...

De une, tu expliqueras ça à la plupart des gens.
De deux, il faut quand même pas être bien dans sa tête pour faire un drag & drop d'un dossier au hasard sur un site au hasard.

Mais, le temps passant, la sécurité se relâche, c'est vrai. À mon sens, ce genre de choses devraient passer par une autorisation forte avant de marcher. Mais bon, la sécurité pose ses problèmes.

[ijk-ref]

- C'est vrai que bon, à part réduire la taille des images avant l'upload, on en a un peu rien à foutre des nouveautés web.
- Redimensionner les images est en principe déjà possible avec l'accès en lecture des input file, canvas et son toDataUrl() ou toBlob(), XMLHttpRequest, et beaucoup de courage et de connaissances. Certes quelques tutoriels sur la manière d'utiliser chacun, ne seraient pas du luxe.

Donc c'est bien ce que je dis : toujours pas grand chose de nouveau et surtout pas efficace.

Si c'est pour écrire un décodeur/encodeur Jpeg en javascript non merci

[thelvin]

Donc c'est bien ce que je dis : toujours pas grand chose de nouveau et surtout pas efficace.

Si c'est pour écrire un décodeur/encodeur Jpeg en javascript non merci

De une, c'est quoi le rapport avec le sujet ? Tout ce qui se fait sur le web ne se fait pas en fonction de tes besoins.

De deux, le décodeur/encodeur, c'est celui de canvas, donc a priori natif.
À l'heure actuelle on doit passer par un codage/décodage en base64 superflu, le décodage se faisant en JavaScript. Ce qui, en effet, est inefficace. Mais les APIs prévues pour éviter ça, la gestion des Blobs, permettront de s'en passer une fois implémentées.

Bon, je reconnais que pour adresser ce problème, une API qui prend un fichier, le considère comme une image et le réduit aux dimensions indiquées avant de l'uploader, ce serait plus pratique.
Manifestement tout le monde s'en fout et on n'est pas en train de parler de ça. Il va falloir apprendre à vivre avec.

[ijk-ref]

(...) Manifestement tout le monde s'en fout et on n'est pas en train de parler de ça. Il va falloir apprendre à vivre avec.

Bah voyons !

Parce que tu crois que le drag & drop c'est principalement pour qui et pour quoi !?

Le drag & drop c'est surtout pour tata Ginette voulant partager quelque chose ou l'envoyer à un professionnel le plus simplement possible. Et franchement si c'est un dossier avec de multi fichiers dedans... c'est à 99% des cas des photos.

Donc c'est parfaitement le sujet.

Sinon trouve moi donc d'autres intérêts majeurs je suis preneur.

[thelvin]

Parce que tu crois que le drag & drop c'est principalement pour qui et pour quoi !?

Le drag & drop c'est surtout pour tata Ginette voulant partager quelque chose ou l'envoyer à un professionnel le plus simplement possible. Et franchement si c'est un dossier avec de multi fichiers dedans... c'est à 99% des cas des photos.

Pas trop mal. Mais tata Ginette ne sait pas ce que c'est qu'un dossier, ne sait pas que ses photos se trouvent dans l'un d'entre eux, et sait encore moins ce que c'est qu'un drag & drop.
Donc ça m'étonnerait qu'elle soit visée.

Les gens visés sont un peu plus éclairés, et partager des photos, qu'ils ne peuvent pas envoyer en format d'origine, est en effet un cas d'utilisation très probable.
Tout comme celui de mettre ses documents administratifs et ses sauvegardes sur un cloud chiffré. Ainsi que n'importe quel type de fichier de taille raisonnable et auquel il puisse tenir.

Alors effectivement t'es pas spécialement hors-sujet, mais t'aurais pu prendre la peine de t'expliquer tout de suite.

[ijk-ref]

Pas trop mal. Mais tata Ginette ne sait pas ce que c'est qu'un dossier, ne sait pas que ses photos se trouvent dans l'un d'entre eux, et sait encore moins ce que c'est qu'un drag & drop.
Donc ça m'étonnerait qu'elle soit visée.

Les gens visés sont un peu plus éclairés, et partager des photos, qu'ils ne peuvent pas envoyer en format d'origine, est en effet un cas d'utilisation très probable.
Tout comme celui de mettre ses documents administratifs et ses sauvegardes sur un cloud chiffré. Ainsi que n'importe quel type de fichier de taille raisonnable et auquel il puisse tenir.

Alors effectivement t'es pas spécialement hors-sujet, mais t'aurais pu prendre la peine de t'expliquer tout de suite.

Tata Ginette de nos jours n'est pas forcement nées dans les années cinquante et est surement à même de savoir utiliser un iPhone. Elle ne connait p'être pas le terme drag & drop... mais il est certains qu'il est plus facile et naturel de lui expliquer comment réaliser cette action que celle via une boite de dialogue.

Sinon... photos ou documents administratifs le problème est le même : Il faut forcement convertir-réduire-chiffrer les fichiers avant de les envoyer. Et Javascript n'est pas du tout fait pour ça ! ! ! Pas plus pour l'implémentation que pour l'exécution.

Ainsi pour que ce drag & drop est réellement un intérêt utile, il faudrait qu'HTML5/Javascript/Css implémente en standard les principaux codeurs, décodeurs, chiffreurs des types de fichiers standards... sinon c'est zéro... autant passer pas un logiciel intermédiaire où une extension/plug-in.

[thelvin]

Sinon... photos ou documents administratifs le problème est le même : Il faut forcement convertir-réduire-chiffrer les fichiers avant de les envoyer.

Non. https et le service d'hébergement s'occuperont du chiffrage. Convertir et réduire, ça a du sens pour les photos et vidéos. Pas pour le reste.

Ainsi pour que ce drag & drop est réellement un intérêt utile, il faudrait qu'HTML5/Javascript/Css implémente en standard les principaux codeurs, décodeurs, chiffreurs des types de fichiers standards...

Moi, la religion, hein... Depuis le début je trouve que fournir des dossiers c'est pas un cas d'utilisation très répandu, mais j'ai pas besoin de lier ça à de la conversion.

Pour les photos et vidéos, ça me semble pas complètement impossible que les codecs soient un jour exposés en natif. Pour le reste des fichiers, ça n'a pas de sens, ça attendra que le W3C soit en charge de définir OpenDesktop sur le web.

[geniium]

le maillon faible de la sécurité, reste l'utilisateur.

[thelvin]

le maillon faible de la sécurité, reste l'utilisateur.

Pour l'instant, je reste assez d'accord qu'il faut pas être bien cuit dans sa tête, pour drag & drop un fichier ou un dossier sur un site auquel on fait pas confiance.

Mais bon, tout doux quand même. À l'heure actuelle, si un site ne gère pas de drag & drop de fichier, et qu'on drag & drop un fichier sur lui, alors le navigateur va changer de page en cours, et afficher l'URL file:// du fichier en question. Ça promet des accidents pour ceux qui ont pris l'habitude de faire ça. Peut-on vraiment dire que c'est leur faute ?

Et puis, il reste qu'à force d'intégrer le bureau aux sites webs, on baisse les barrières de protection naturelles qu'il y avait entre le bureau et les sites webs. Moi je dis ce n'est pas vraiment la faute de l'utilisateur.
Il faudrait que par défaut ça ne fonctionne pas, et mettre des barrières compliquées pour le faire fonctionner, genre comme accéder à un site auto-signé.
Pire, je préférerais que cela ne soit possible qu'à condition qu'une tierce partie se porte garante pour le site, et les utilisateurs pourraient choisir quelles tierces parties. Dans le monde linux c'est comme ça qu'on installe ses programmes : on définit une liste de sites qui fournissent des programmes libres, et s'en portent garants. Ça aurait des défauts, semblables aux blacklists de spammeurs. Mais la sécurité n'a pas d'idéal, et il reste possible aux power-users de la gérer eux-mêmes.