Carnet Wiki

Proposition de fonctionnement alternatif pour l’insertion des documents

Version 2 — September 2010 Joseph

Le fonctionnement des modèles pour l’insertion des documents soulève régulièrement des questions, notamment parce <doc13>, <img13> ou encore <emb13> ne produisent pas le même résultat et que ce résultat, pour les images, dépend du fait d’être dans le portfolio ou non.
.
Comme l’écrit Romy,

<blockquote class="spip">

Qui sait expliquer clairement la différence entre les « images » et les « documents » de SPIP ? Quand faut-il utiliser le raccourci d’insertion <img314>, celui <doc314> ou encore <emb314> ? et quelles sont précisément leurs différences ? Pourquoi est-ce si difficile à retenir ?

</blockquote>

(Source : http://romy.tetue.net/mais-ou-est-p...)

Sur la liste SPIP-Zone, Cédric expliquait :

<blockquote class="spip">

Le sujet est un serpent de mer, contraint par la compatibilté ascendante. Pour le moment on a fait le choix de ne pas la casser, ce qui a des limites.

</blockquote>

(Source : http://permalink.gmane.org/gmane.co...)

Avant de poursuivre la discussion, on pourra lire la documentation officielle à cette adresse http://www.spip.net/fr_article3715.html.

<del >

Objectif de la présente proposition

La présente proposition vise à définir un comportement unifié des différents modèles d’incrustation en supprimant la contrainte de rétrocompatibilité. Ce comportement unifié pourra ensuite être implémenté dans un plugin dédié annonçant clairement la perte de rétrocompatibilité. Ainsi, chacun sera libre ou non d’adopter ce nouveau comportement des modèles en toute connaissance de cause.

Ce plugin fournira également une aide en ligne actualisée ainsi qu’une aide à l’insertion des modèles (au travers du plugin inserer_modeles en cours de développement).

Proposition

<doc123>, sans paramètre additionnel, quelque le soit le type et le mode du document, affichera systématiquement la vignette du document (vignette personnalisée si existante sinon icône) avec un lien pointant sur le document et la légende (titre, descriptif et crédits [1]).

<doc123|embed> sera équivalent à <emb123>.

L’incrustation des documents les modèles dédiés (<image>, <audio>, <video>, <text> et <application>) sera également possible.

Si le document 123 est une vidéo, alors <doc123|embed>, <emb123> et <video123> seront équivalents.

Par souci de compatibilité, <img> sera maintenu mais équivalent à <image>. Autrement dit, si 45 est une image, <img45>, <image45>, <emb45> et <doc45|embed> seront équivalents.

Pour compatibilité avec le lecteur multimedia, <doc123|player> sera équivalent à <doc123|emb> ou <emb123> ou . Ce sont les modèles <video> et audio qui se chargeront d’intégrer ou non le player selon le type de fichier.

Quelque soit l’appel utilisé, on pourra systématiquement indiquer |legende=non si on ne souhaite pas afficher la légende (qui sera toujours affichée par défaut) ou bien |legende=mon texte si on souhaite afficher une légende personnalisée.

Les paramètres hauteur et largeur pourront être utilisés quelque soit le type de document incrusté. On pourra utiliser de manière alternative |width= et |height=.

Un paramètre |taille= acceptant trois valeurs petit, moyen et grand peut être utilisé de manière alternative à hauteur et largeur pour définir trois tailles standards (paramétrables dans l’interface privée, par défaut 100 px, 250px, 500px [2]).

Le paramètre lien pour les images est maintenu. Il permet de spécifier le lien sur lequel point l’image. S’il est absent, alors le lien pointe sur l’image elle-même. On peut forcer l’absence de lien avec |lien=non.

Au final, il est possible d’utiliser uniquement le raccourci <doc> si on le souhaite, ou bien d’utiliser les autres raccourcis, sachant que le fonctionnement reste identique quelque soit le raccourci utilisé.

Objectif de le proposition 2

La présente proposition vise à définir un comportement unifié des différents modèles d’incrustation. Ce comportement unifié pourra ensuite être implémenté dans un premier temps dans un plugin dédié avant d’envisager son intégration éventuelle au core.

Ce plugin fournira également une aide en ligne actualisée ainsi qu’une aide à l’insertion des modèles (au travers du plugin inserer_modeles en cours de développement).

Les modèles existants (doc, emb, img, image, audio, video, text, application) ne seront pas modifiés afin d’assurer la rétrocompatibilité.

Proposition 2

Toutes les insertions se font au travers d’un unique modèle <document>. Volontairement, afin de distinguer le nouveau système du système actuel, on n’a pas repris <doc>.

Les deux usages principaux sont <documentXX|vignette> et <documentXX|inclus>. Pour ceux préférant l’anglais, <documentXX|embed> sera équivalent à <documentXX|inclus>.

Si <documentXX> est appelé sans paramètre, cela sera équivalent à <documentXX|vignette>.

<documentXX|vignette>, sans paramètre additionnel, quelque le soit le type et le mode du document, affichera systématiquement la vignette du document (vignette personnalisée si existante sinon icône) avec un lien pointant sur le document et la légende (titre, descriptif et crédits [3]).

Reprenant le fonctionnement actuel de <emb>, le modèle document_embed.html sous-traitera le travail à plusieurs modèles en fonction du type MIME du document : document_image.html, document_audio.html, document_video.html, document_text.html et document_application.html.

Dès lors, il sera possible d’utiliser également des appels de la forme <documentXX|image>, <documentXX|audio>, <documentXX|video>, <documentXX|text> et <documentXX|application>.

<documentXX|inclus> et <documentXX|image> produiront exactement le même résultat [4]

Quelque soit l’appel utilisé, on pourra systématiquement indiquer |legende=non si on ne souhaite pas afficher la légende (qui sera toujours affichée par défaut) ou bien |legende=mon texte si on souhaite afficher une légende personnalisée.

Les paramètres hauteur et largeur pourront être utilisés quelque soit le type de document incrusté. On pourra utiliser de manière alternative |width= et |height=.

Un paramètre |taille= acceptant trois valeurs petit, moyen et grand peut être utilisé de manière alternative à hauteur et largeur pour définir trois tailles standards (paramétrables dans l’interface privée, par défaut 100 px, 250px, 500px [5]).

Le paramètre lien pour les images est maintenu. Il permet de spécifier le lien sur lequel pointe l’image. S’il est absent, alors le lien pointe sur l’image elle-même. On peut forcer l’absence de lien avec |lien=non.

L’alignement (left, right ou center) sera toujours précisé de la même manière.

Au final, un seul raccourci <document> sera nécessaire avec deux appels principaux : <documentXX|vignette> et <documentXX|inclus>.

Interaction avec le Lecteur Multimédia

Si le lecteur multimédia est activé, il serait bon que <documentXX|inclus> fonctionne directement avec ce dernier sans avoir besoin de préciser |player. On peut donc envisager que le Lecteur Multimédia puisse surcharger directement modeles/document_audio.html et modeles/document_video.html.

Un modèle par type de fichier ?

Doit-envisager la possibilité d’avoir la possibilité de faire un modèle d’inclusion spécifique par type de fichier ? Cela signifierait que l’on regarde d’abord l’existence d’un modèle modeles/document_groupeMIME_extension.html, qu’on utilise s’il existe, et sinon on utilise le modèle générique modeles/document_groupeMIME.html.

Cela permettrait de faire évoluer le système assez simplement en surchargeant le fonctionnement que pour certaines extensions (le lecture multimedia ne gère que certains types de fichiers par exemple).

Pour les images, on pourrait ainsi avoir un modèle générique modeles/document_image.html et un modèle spécifique pour le SVG : modeles/document_image_svg.html.

Noms alternatifs pour document

<document> est long à écrire. Alternative :

  • <media>
  • <file>
  • <doc>, attention, cela peut entraîner une confusion avec l’ancien système. De plus, le raccourci <doc12> pour <doc12|vignette> ne peut être utilisé pour rétrocompatibilité.
  • <doc12|ico>, <doc12|inc>, <doc12|emb>.