(mail du 28 septembre qui visiblement n'est jamais parti.)
Deux remarques liées à cette nouvelle formulation :
1. Si on évolue vers une notion plus riche de portfolio, Romy
proposait de faire *des* portfolios, pas forcément liés à un article,
ou encore permettre de lier plusieurs portfolios à un même article.
Tant qu'à faire de refondre, autant voir grand 
De mémoire, dans la proposition de Romy, elle avait utilisée le terme d'album, un album étant un groupement d'objet. Elle proposait un modèle associé <album12>. Je ne me souviens pas si elle évoquait la possibilité de joindre un album à objet (un article par exemple).
2. tu écris : "Le champs mode de la table spip_documents ne prendrait
dans ce contexte que deux valeurs : document ou vignette."
=> je conçois qu'on abandonne la valeur "image" pour les nouveaux
documents (si tant est qu'on arrive à une interface qui permet autant
de choses), mais alors :
-- que deviendraient les images d'illustration d'un site existant ?
elles prendraient la valeur "vignette" ? pourquoi dès lors ne pas leur
conserver la valeur "image" et traiter cette valeur comme équivalente
?
-- comment fait-on concrètement (interface) pour mettre une image
d'illustration dans un article, sans qu'il apparaisse (par exemple) en
pièce jointe dans les flux rss ?
-- si tu te bases sur les spip_liens_documents pour savoir si un doc
est dans le portfolio, comment élimines-tu les images d'illustration
de la "liste de toutes les photos" ? en te basant sur la taille du
fichier ?...
Qu'appelles-tu les images d'illustration ? S'il s'agit des images qui sont incrustées dans l'article, il y a le critère vu qui permet de connaître les images (et tout autre doc) appelées dans l'article.
A titre personnel, j'ai souvent été perturbé par le fait que les images étaient soient des illustrations, soient dans un portfolio, mais jamais considérées comme un simple document attaché à un article (au même titre qu'un PDF).
Je ne connais pas assez bien l'historique de SPIP, mais, si j'ai bien lu La boucle DOCUMENTS - SPIP, le mode image a été mis en place sous la 1.4 pour distinguer initialement les images que l'on souhaitait incruster dans l'article (illustration) des images que l'on souhaite joindre à l'article (considérées alors dans le portfolio).
La logique du squelette dist reprend cela :
Les images illustrations ne sont pas jointes à l'article.
Les autres images sont affichées dans un portfolio à la fin de l'article, séparément des autres documents.
Ceci dit, cela n'empêche pas qu'une image puisse être placées dans les illustrations sans être appelée dans l'article (elle sera alors affichée nulle part) ou bien qu'une image soit dans le portfolio mais aussi incrsutée dans l'article (elle sera alors affichée deux fois, dans l'article et dans le portfolio).
Entre temps, il y a le critère {vu} qui a fait son apparition ({vu} - SPIP) mais je ne sais pas à partir de quelle version de SPIP, critère dont il n'est d'ailleurs pas fait mention sur la page de la boucle DOCUMENTS.
Ce critère repère les documents qui sont appelés dans l'article (ou la brève, ou la rubrique...) via un des trois modèles <doc>, <img> ou <emb> (à ce propos il faudrait un pipeline pour ce critère voir autre mail).
Dès lors, il serait possible de se passer de la distinction illustration/portfolio pour les images, et d'exclure simplement, à la fin de l'article les images qui ont été incrustées dans l'article.
Le squelette Zpip-dist utilise ce critère {vu}. Tout document qui est incrusté (<img> ou <emb>) ou affiché (<doc>) dans l'article est exclu de la liste du portfolio et des documents joints à la fin. Par contre, le mode de l'image influe puisque les images en mode=image (illustration) sont également exclues de la liste des documents joints.
Au passage, on remarquera que ces deux squelettes utilise {extension IN png,jpg,gif} pour sélectionner les images, ne tenant du coup pas compte des fichiers BMP et TIF qui, d'après la table spip_types_documents, peuvent également appartenir au portfolio.
D'autres squelettes peuvent très bien avoir implémenter les choses différemment.
Dans certains, on peut vouloir considérer une image comme un simple document joint, au même titre qu'un PDF par exemple, et de souhaiter l'afficher de la même manière (donc en dehors du portfolio mais dans la liste des documents).
Dans un autre squelette (dont j'ai oublié le nom), le fonctionnement était :
- Une image est inclue dans l'article (identifiée avec vu=oui et considérée alors comme une illustration) => on ne l'affiche pas à la fin de l'article
- Une image n'est pas inclue dans l'article et déposée dans le portfolio => elle est affichée à la fin de l'article dans une présentation de type portfolio
- Une image n'est pas inclue dans l'article et n'est pas déposée dans le portfolio => elle est affichée parmi la liste des autres documents joints
Ce squelette ne retenait du mode de l'image que la notion de portfolio (dedans ou dehors). La notion d'illustration dépendant pour sa part du critère {vu}.
Si on se base sur ce critère, c'est très facile concrètement d'exclure dans un flux RSS (pour reprendre ton exemple) les images directement incrustées dans le texte.
Tu sembles dire que la difficulté est celle de la structure des
données. Mais en fait c'est surtout un problème d'interface.
Pas seulement. Avec l'arrivée de la médiathèque (mais c'était déjà possible avec certains plugins), un document devient indépendant de l'objet auquel il est lié et surtout, il peut être lié à plusieurs objets.
Autrement dit, une image n'a pas forcément le même rôle dans l'article 2 et l'article 4. Elle peut être incrustée dans le premier et simplement jointe au second.
Le critère {vu} est calculé objet par objet et cette information est stockée à juste titre dans spip_documents_liens.
Le mode d'un document est stocké dans spip_documents. Ce champs permet notamment de distinguer les vignettes (et il bien sa place dans spip_documents). Il est aussi utilisé pour distinguer les images dans le portfolio ou non. Or cette information ne dépend pas à mon avis du document proprement dit mais de son usage dans un article.
Par ailleurs, une image est soit dans le portfolio soit considérée comme une illustration. Or, il me semble pas que les deux concepts soit complémentaires. Une image est incrustée ou non dans un document (donc utilisée ou non comme image d'illustration, calculé automatiquement). Si ce n'est pas le cas, souhaite t on la présenter dans un portfolio ou comme un simple document joint (choix de présentation du rédacteur).
Or là j'ai l'impression qu'on retombe sur l'interface actuelle
("déposer dans le portfolio"), qui est critiquée parce que pas claire.
L'interface n'est pas claire car les concepts, et du coup les traitements faits par les squelettes, ne le sont pas pour le rédacteur de base.
Est-ce qu'on peut par ailleurs imaginer une interface bien plus smart
à base de drag/drop dans la zone de texte ? Là clairement si je drop
une petite image elle peut apparaître plein pot (mais que se
passe-t-il si je drop une photo de 2000px de large ? oups ? on la
retaille automatiquement ? on stocke l'original ?)
-- Fil
Pourquoi faudrait-il retailler l'image ? Je ne vois pas où est le soucis. Si tu veux parler des images qui sont incrustées dans un article, c'est en général le squelette qui prévoit sont redimensionnement en utilisant |image_reduire.
Tous les squelettes ne gèrent pas les documents de la même façon et plusieurs manières de les présenter peuvent exister selon le squelette.
Ma question serait plutôt de savoir comment faire pour que l'interface puisse être cohérente entre l'espace privé et l'espace publique.
Je sais bien que la question de la compatibilité ascendante est complexe. Cela étant dit, je ne sais pas non plus quels sont les usages des rédacteurs de SPIP. A titre personnel, je n'ai jamais eu de comportement de rédaction unifié avec la question du mode des images car je ne l'ai jamais vraiment compris jusqu'à ce que, dans le cadre de la réflexion sur les modèles de documents, je me plonge dedans.
D'autant plus que le comportement des images et documents joints change parfois d'un squelette à un autre (cf. exemples plus haut).
Je ne dis pas avoir la solution miracle. Mais il me semble qu'une réflexion partagée sur le sujet serait la bienvenue.
Cordialement
Joseph
