Pourquoi peut-on l'utiliser pour l'upload massifs via tmp/upload pour
des documents et pas pour des images ?
Pourquoi peut-on l'utiliser pour l'upload massifs via tmp/upload pour
des documents et pas pour des images ?
Parce que si tes "images" font plus de 2Mo ça sert à rien de les
mettre comme "images".
-- Fil
Je suis d'accord mais pour une galerie on peut vouloir importer 50
images d'un coup.
Comment fait-on sans ftp ?
.Gilles
Et même pour des images de moins de 2 Mo, d'ailleurs !
C'est une vieille discussion qui revient de temps en temps, mais je pense toujours que ces deux systèmes séparés devraient fusionner, d'autant plus qu'on a bien <emb> pour les images ajoutées comme documents mais qu'on veut finalement inclure directement...
-Nicolas
Je suis d'accord mais pour une galerie on peut vouloir importer 50
images d'un coup.
Comment fait-on sans ftp ?
mais dans une galerie ce sont des "documents"; je l'ai fait hier
encore sur mon site de photo, par ftp
-- Fil
Et même pour des images de moins de 2 Mo, d'ailleurs !
l'upload ftp n'est pas réservé aux documents de plus de 2Mo
je dis juste qu'il ne faut pas mettre d'image de plus de 2Mo. Etant
entendu que dans SPIP les "images" sont des éléments inline du texte
C'est une vieille discussion qui revient de temps en temps, mais je pense
toujours que ces deux systèmes séparés devraient fusionner, d'autant plus
qu'on a bien <emb> pour les images ajoutées comme documents mais qu'on veut
finalement inclure directement...
oui et on attend toujours un prototype de meilleur système, moi je
n'ai pas d'idée
-- Fil
Et même pour des images de moins de 2 Mo, d'ailleurs !
l'upload ftp n'est pas réservé aux documents de plus de 2Mo
je dis juste qu'il ne faut pas mettre d'image de plus de 2Mo. Etant
entendu que dans SPIP les "images" sont des éléments inline du texte
Oui, mais si on veut des « images » et non des « documents » de faible taille, qui tiennent directement à l'affichage, on ne peut pas utiliser "upload".
Des flopées d'icônes, par exemple.
C'est une vieille discussion qui revient de temps en temps, mais je pense
toujours que ces deux systèmes séparés devraient fusionner, d'autant plus
qu'on a bien <emb> pour les images ajoutées comme documents mais qu'on veut
finalement inclure directement...oui et on attend toujours un prototype de meilleur système, moi je
n'ai pas d'idée
Bin on vire le bloc image, et on ne laisse que le bloc document, non ? On a déjà <emb>, il suffit de lui mettre <img> en alias.
-Nicolas
Oui, mais si on veut des « images » et non des « documents » de faible
taille, qui tiennent directement à l'affichage, on ne peut pas utiliser
"upload".Des flopées d'icônes, par exemple.
C'est un usage pas tout à fait courant, qui ne mérite pas (à mon avis)
d'alourdir l'interface.
Bin on vire le bloc image, et on ne laisse que le bloc document, non ? On a
déjà <emb>, il suffit de lui mettre <img> en alias.
Comme tu sais il y a beaucoup plus de cas que ça, donc il "suffit" pas
de mettre <img> en alias.
-- Fil
Pareil. D'autant que je trouve qu'en général, les pistes proposées ne partent pas dans la bonne direction. On a plusieurs difficultés:
– la séparation la plus forte n'est pas entre images et «documents», contrairement à une idée reçue (et contrairement à l'interface graphique qui, justement, sert à gérer ces éléments);
– la plus forte séparation est, à mon avis, entre documents insérés dans le texte et documents joints présentés séparément.
Là où il y a des blocages difficiles à surmonter:
– les sites existants... on ne peut pas prévoir quelles utilisations diverses et variées ont été faites;
– l'interface graphique actuelle se base sur la différence entre «images» et «documents», alors que ça n'est pas la différence fondamentale, alors que la visualisation de l'article évoque plus un «portfolio» et des «documents joints» en plus des éléments insérés dans le texte;
– le gros blocage: la souplesse épatante du système actuel qui permet tout de même d'insérer dans le texte n'importe quel «document» joint, y compris une image via <emb>, qui rend difficile la séparation forte entre documents dans le texte et documents hors texte;
– petite complication ergonomique: la présence de <img> et <doc> pour les images, je ne suis pas certain que grand monde y pige quelque chose; ainsi que le comportement différent de <doc> selon qu'on a installé une image en «image» ou en «document joint» (dans le premier cas: image avec titre; dans le second: vignette avec titre).
Si on veut faire évoluer le système, il me semble que c'est en se basant plutôt sur une distinction entre éléments destinés à être installés dans le texte (donc non seulement des images, mais aussi des «documents»), et les éléments destinés à être associés hors texte.
A*
Gilles VINCENT a écrit :
Je suis d'accord mais pour une galerie on peut vouloir importer 50
images d'un coup.
Comment fait-on sans ftp ?mais dans une galerie ce sont des "documents"; je l'ai fait hier
encore sur mon site de photo, par ftp
Oui, je ne pensais pas à une galerie automatique, mais à des photos
qu'il voudrait ajouter au milieu de son article.
50 était peut-être un peu exagéré, mais il doit bien y avoir des
familles qui ont fait pire pour des sites perso avec leurs photos de
mariage 
.Gilles
Fil a écrit :
C'est un usage pas tout à fait courant, qui ne mérite pas (à mon avis)
d'alourdir l'interface.Bin on vire le bloc image, et on ne laisse que le bloc document, non ? On a
déjà <emb>, il suffit de lui mettre <img> en alias.
En l'occurence c'est pas un alourdissement mais carrément un allègement !!!
Comme tu sais il y a beaucoup plus de cas que ça, donc il "suffit" pas
de mettre <img> en alias.
moi en tout cas je sais pas... j'ai pas vu !
Parfois par contre j'aimerais mettre l'icone d'un document à ouvrir
"inline" dans le texte. je sais pas non plus...
<emb> ou <img> sur un doc RTF par exemple ne fait rien,
mais pourrait le faire peut être ?
JL
On a plusieurs difficultés:
– la séparation la plus forte n'est pas entre images et «documents», contrairement à une idée reçue (et contrairement à l'interface graphique qui, justement, sert à gérer ces éléments);
– la plus forte séparation est, à mon avis, entre documents insérés dans le texte et documents joints présentés séparément.
Les documents gérés lors de l'édition, et ceux gérés lors de la visualisation (je n'utilise jamais), pourraient avoir un comportement différent, cela expliquerait qu'il y ait deux endroits de ce type.
Là où il y a des blocages difficiles à surmonter:
– les sites existants... on ne peut pas prévoir quelles utilisations diverses et variées ont été faites;
C'est l'avantage de faire une 2.0 plutôt qu'une 1.9.3, cela suppose (selon les règles communément admises dans le logiciel) que vous pouvez casser des choses.
Il suffit que les changements impactant l'existant soient bien documentés lors de la sortie de la première beta.
– l'interface graphique actuelle se base sur la différence entre «images» et «documents», alors que ça n'est pas la différence fondamentale, alors que la visualisation de l'article évoque plus un «portfolio» et des «documents joints» en plus des éléments insérés dans le texte;
Oui, d'où inadéquation de l'interface actuelle, que je soulignais.
– le gros blocage: la souplesse épatante du système actuel qui permet tout de même d'insérer dans le texte n'importe quel «document» joint, y compris une image via <emb>, qui rend difficile la séparation forte entre documents dans le texte et documents hors texte;
<emb> sur les docs joints justifie déjà la suppression du bloc image, à mon sens. Pour l'utilisation dans le texte ou hors texte, si l'idée est de les laisser mélangés et non de les séparer clairement comme je le suggère un peu plus haut, une simple case à cocher « rendre visible dans le "porte documents" » suffirait sans doute, non ?
– petite complication ergonomique: la présence de <img> et <doc> pour les images, je ne suis pas certain que grand monde y pige quelque chose;
C'est clair ! Des images peuvent se comporter comme des documents avec <doc>, mais les documents peuvent se comporter comme des images avec <emb>. Incompréhensible, et point de blocage de nombreux utilisateurs.
ainsi que le comportement différent de <doc> selon qu'on a installé une image en «image» ou en «document joint» (dans le premier cas: image avec titre; dans le second: vignette avec titre).
Idem.
Si on veut faire évoluer le système, il me semble que c'est en se basant plutôt sur une distinction entre éléments destinés à être installés dans le texte (donc non seulement des images, mais aussi des «documents»), et les éléments destinés à être associés hors texte.
Cf ma proposition, donc. Les éléments dans le texte sont ajoutés lors de l'édition, et ceux hors texte, destinés à un "porte documents" ("portfolio" est trop restrictif à mon sens), sont ajoutés lors de la visualisation, comme dans les rubriques.
On gagnerait en intuitivité et uniformité.
-Nicolas
C'est tout vu : les modèles "img" et "emb" (ici c'est image.html qui
sera utilisé) sont différents
Oui, mais si on veut des « images » et non des « documents » de faible
taille, qui tiennent directement à l'affichage, on ne peut pas utiliser
"upload".
Des flopées d'icônes, par exemple.C'est un usage pas tout à fait courant, qui ne mérite pas (à mon avis)
d'alourdir l'interface.
Euh... là on parle justement de l'alléger, en arrêtant de distinguer dans l'interface des choses qu'on ne distingue finalement pas tant que ça (ou pas de la même manière) dans leur utilisation finale.
Bin on vire le bloc image, et on ne laisse que le bloc document, non ? On a
déjà <emb>, il suffit de lui mettre <img> en alias.Comme tu sais il y a beaucoup plus de cas que ça, donc il "suffit" pas
de mettre <img> en alias.
Oui, je sais bien qu'ils ne sont pas identiques pour l'instant, mais c'est justement l'un des problèmes du système actuel. Mais on discute d'une éventuelle meilleure cible.
-Nicolas
Oui, je sais bien qu'ils ne sont pas identiques pour l'instant, mais c'est
justement l'un des problèmes du système actuel. Mais on discute d'une
éventuelle meilleure cible.
OK mais il ne faut pas se leurrer, ça va être assez compliqué à améliorer.
Et, quelle que soit la solution qu'on trouvera il *faut* qu'on puisse
mettre à jour les dizaines de milliers de sites existants.
(Au pire du pire on peut imaginer un switch "ancien système/nouveau
système", mais ça serait vraiment un crève coeur d'en arriver là.)
-- Fil
Oui, je sais bien qu'ils ne sont pas identiques pour l'instant, mais c'est
justement l'un des problèmes du système actuel. Mais on discute d'une
éventuelle meilleure cible.OK mais il ne faut pas se leurrer, ça va être assez compliqué à améliorer.
Mais ça n'empêche pas d'en parler...
Et, quelle que soit la solution qu'on trouvera il *faut* qu'on puisse
mettre à jour les dizaines de milliers de sites existants.
Si cela nécessite des changements sur des contenus déjà saisis ou des squelettes, ce sera sans doute compliqué, mais il est évident qu'il faudra limiter la douleur de la migration.
(Au pire du pire on peut imaginer un switch "ancien système/nouveau
système", mais ça serait vraiment un crève coeur d'en arriver là.)
Tu veux dire faire perdurer l'ancien système en plus du nouveau, avec une option de configuration, le temps que les gens migrent ?
Ca me semble encore plus compliqué et source de problèmes ultérieurs qu'une migration forcée, mais en douceur.
-Nicolas
Une hypothèse serait de conserver la structure de données actuelle
mais d'unifier l'interface.
On présenterait une seule interface d'envoi, mais avec une case à
cocher sur les petites images, pour les basculer en illustration.
Cela dit si tant est qu'on y arrive, ça sera pour la 2.1
-- Fil
Nicolas Hoizey wrote:
Mais ça n'empêche pas d'en parler...
+1
Une première remarque: si les avis divergent autant, ça veut dire que la solution réside dans une interface dans laquelle on peut faire varier la manière dont les documents sont présentés.
Une deuxième remarque: je ne pense pas que l'on puisse d'avance fixer ce qui sera inséré et ce qui ne le sera pas, d'autant qu'on peut aussi vouloir faire les 2. Et il faut aussi compter avec le fait que les nouveaux modèles d'incrustation spécialisant emb (image, audio, video, text, application) avec leur application autoamtique de filtre encore plus spécialisés (csv et html actuellement) ont rallongé la liste des documents incrustables et que ça va certainement continuer.
Pour ma part, ce qui me paraitrait plus rationnel c'est de se fonder sur une classification existante, savoir MIME, avec ses 5 groupes listés ci-dessus. A peu de choses près, le groupe "img" correspond au "portfolio" de SPIP, on ne changerait donc pas beaucoup l'apparence de l'interface en ce qui les concerne. En revanche on diviserait en 4 le bloc "documents" actuels, mais il faudrait toutefois pouvoir déclarer qq part que certains sous-type relèvent d'un autre groupe que l'officiel (XHTML est dans "application" et pas dans "text" !). Avec ça, on pourrait faire sauteur la différence entre image et document imposée incompréhensible par l'interface de téléchargement.
Committo,Ergo:Sum