Cédric a écrit :
> New Revision: 13309
> Log:
> revert de [13279] qui entraine une double legende + une legende
> cassee flotante sur les images
> 1.9.x n'affichait deja pas de legendes sous les images avec le modele <emb>
Alors, est-ce que d'une autre manière SPIP va nous donner la possibilité d'afficher une image pleine taille avec titre et desciption en légende ? Ou faut-il utiliser un modèle personnalisé ?
Pour ma part cela semble un besoin si évident, que cela devrait être dans SPIP « vanille ».
Cédric a écrit :
> New Revision: 13309
> Log:
> revert de [13279] qui entraine une double legende + une legende
> cassee flotante sur les images
> 1.9.x n'affichait deja pas de legendes sous les images avec le modele <emb>
Alors, est-ce que d'une autre manière SPIP va nous donner la possibilité d'afficher une image pleine taille avec titre et desciption en légende ? Ou faut-il utiliser un modèle personnalisé ?
je crois pas que il y ait eu ça dans SPIP.
En ce qui concerne la gestion des documents, images, portfolio, pas portfolio etc ... c'est un dédale que je n'ai toujours pas compris correctement pour ma part.
donc avec un modele <doc qui permettrait toutes les options explicitement.
Je pense qu'on peut espérer avoir ça bientôt dans le plugin mediatheque !
Cédric
Pour ma part cela semble un besoin si évident, que cela devrait être dans SPIP « vanille ».
oui, clairement, mais il y a tant de besoins évidents que SPIP ne remplit pas, souvent pour de mauvaises raison, que cet argument ne vaut plus pour grand monde, malheureusement.
Alors, est-ce que d'une autre manière SPIP va nous donner la possibilité d'afficher une image pleine taille avec titre et desciption en légende ? Ou faut-il utiliser un modèle personnalisé ?
je crois pas que il y ait eu ça dans SPIP.
Il semblerait qu'on ait perdu cette fonction avec la 1.9.
donc avec un modele <doc qui permettrait toutes les options explicitement.
Je pense qu'on peut espérer avoir ça bientôt dans le plugin mediatheque !
C'est un besoin tellement « central » d'améliorer la gestion des documents -- pourquoi est-ce que cela doit aller dans un plugin au lieu de dans le core ?
Pour remplacer les documents en laissant les identifiants en place, actuellement j'utilise un squelette perso avec les crayons. C'est extrêment utile.
Une situation avec laquelle j'ai été confronté plusieurs fois ces derniers temps : on trouve un bug dans SPIP, un dev avec une réactivité incroyable propose une correction, mais mettre à jour SPIP vers la version corrigée ferait qu'un plugin essentiel (Indexation, Accès Restreint, Barre typo...) ne marchera plus. Cela me fait bcp. hésiter maintenant avant d'adopter un plugin.
donc avec un modele <doc qui permettrait toutes les options explicitement.
Je pense qu'on peut espérer avoir ça bientôt dans le plugin mediatheque !
C'est un besoin tellement « central » d'améliorer la gestion des documents -- pourquoi est-ce que cela doit aller dans un plugin au lieu de dans le core ?
Le modèle de développement que l'on a utilisé pour la 2.0 ne tient plus la route. Travailler sur tous les sujets en parallèles directement sur le tronc entraine les plus gandes difficultés pour sortir des release stables : il y a toujours un chantier qui n'est pas fini ni prêt.
J'essaye donc, pour ma part, de travailler dans un autre cadre. Tout ce que je fais sera bien sûr intégrable au core si il en est décidé ainsi.
L'autre point à prendre en compte est que tout ce qui concerne l'espace privé, son ergonomie et ses fonctionnalités fait débat, et qu'y travailler dans le core est épuisant.
Je préfère donc maintenant travailler hors core, sans certaines contraintes que je ne supporte plus, et si ça ne plait pas, ça restera en dehors du core. Si c'est incontournable, les utilisateurs sauront l'imposer.
Pour remplacer les documents en laissant les identifiants en place, actuellement j'utilise un squelette perso avec les crayons. C'est extrêment utile.
Une situation avec laquelle j'ai été confronté plusieurs fois ces derniers temps : on trouve un bug dans SPIP, un dev avec une réactivité incroyable propose une correction, mais mettre à jour SPIP vers la version corrigée ferait qu'un plugin essentiel (Indexation, Accès Restreint, Barre typo...) ne marchera plus. Cela me fait bcp. hésiter maintenant avant d'adopter un plugin.
Oui, clairement. Sortir une nouvelle version de SPIP perd beaucoup de son intérêt si on a pas fait le travail en amont pour permettre aux devs de porter leurs plugins sur la nouvelle version. Cela explique sans doute aussi le délai pour faire une release stable. En ce qui me concerne je n'ai commencé le portage de mes plugins que depuis cet été, et tout n'est pas encore porté.
Si, je confirme : en SPIP 1.8, les images ET documents étaient dotés de légendes (titre+descriptif) lorsqu'ils étaient insérés dans le texte avec le raccourci <embXX>.
Je viens de ré-installer un SPIP 1.8 pour vérifier, mais je n'ai pas encore pris le temps de faire ni d'envoyer une capture d'écran.
les modeles sont apparus dans la 1.9.1, de mémoire. Et je me souviens avoir ramé pour faire des jeux de tests dans tous les sens et vérifier que c'etait iso fonctionnel.
Je pencherai donc pour la 1.9 tout court, effectivement, mais pas a cause des modeles.
Je pencherai donc pour la 1.9 tout court, effectivement, mais pas a cause des modeles.
en 1.9.0 (dans ecrire/inc/documents.php) :
// pour un document affiche avec le raccourci <IMG> on a
// $mode == 'document' et $type_aff == 'IMG'
// inversement, pour une image presentee en mode 'DOC',
// $mode == 'vignette' et $type_aff == 'DOC'
...
// Preparer le texte sous l'image pour les <DOC>
if ($type_aff == 'DOC') {
if (strlen($titre))
$txt = "<div class='spip_doc_titre'><strong>"
. $titre
. "</strong></div>\n";
if (strlen($descriptif))
$txt .= "<div class='spip_doc_descriptif'>$descriptif</div>\n";
mais il y aurait (?) un commando de bérets mauves
de la Section Permanente d'Intervention Péhachpéienne
(la bien connue SPIP) qui serait sur le coup...
Je reviens sur ce point, car ça me semble un appauvrissement dommageable de SPIP.
Comme le signalait Paolo au début de ce thread, en décembre 2008, nous avons effectivement perdu la légende des documents insérés avec <emb>, à partir de SPIP 1.9.
Pour les images, ce n'est pas grave, puisqu'on peut obtenir une image légendée avec le modèle <doc>. Par contre, il n'est plus possible d'avoir, comme auparavant, une vidéo avec sa légende. Cela masque une information et rend son affichage beaucoup plus difficile puisqu'il faut pour cela confectionner un modèle personnalisé (là où auparavant, il suffisait de saisir, ou pas, une légende pour l'afficher, ou pas).
Il me semble dommage d'avoir perdu en diversité et restreint les possibles par défaut : <img> et <emb> se ressemblent maintenant tellement qu'il n'y a plus grand intérêt à les maintenir.
Je ne suis pas sûr de comprendre. Ces deux modèles sont de toutes façons obsolètes depuis l'introduction des filtres d'incrustation fondé sur les familles MIME, savoir audio, image, text, video cf : http://www.spip.net/fr_article3715.html
Si ces 4 modèles ont laissé tomber des choses intéressantes figurant dans img et emb, il suffit de les reporter dans ces 4 là, mais certainement pas dans emb qui n'est là que par souci de compatibilité et s'empresse de déléguer à celui des 4 autres qui est concerné.
pardon de m'en mêler, mais le fait que <img> ou <emb> soient si proches est dommageable en quoi?
Un doc semble t-il reste un doc dans n'importe quelle boucle si peu quelle soit bien montée. Le <emb> n'est il pas là non plus pour maintenir une manière d'être compatible avec toutes les autres modes moins un?
Désolé pour le dérangement mais c'est juste mon avis et je me vois mal revenir en arrière maintenant comme par exemple la suppression des tailles de l'embed de la 1.81. à la 1.83 si je ne me trompe
A moins que je ne sois hors sujet, dans ce cas, merci de ne pas tenir compte de ma remarque
Il me semble dommage d'avoir perdu en diversité et restreint les possibles par défaut : <img> et <emb> se ressemblent maintenant tellement qu'il n'y a plus grand intérêt à les maintenir.
Je ne suis pas sûr de comprendre. Ces deux modèles sont de toutes façons obsolètes
Je ne suis pas sur de comprendre.
les raccourcis <img> et <emb> n'ont rien d'obsolètes et restent les raccourcis documentés, voire proposés dans l'interface rédactionnelle de SPIP.
Que techniquement cela repose sur ces modeles est une chose qui est très bien, mais c'est de la technique.
Les pauvres rédacteurs ont déjà toutes les peines du monde à manipuler 3 raccourcis <img> <doc> et <emb>, démultiplier ce dernier en 5 différents (text,audio,image,video et application) n'apporte rien à l'utilisateur sinon de la confusion, alors que le dit <emb> est capable par lui même de déterminer quel modèle sous-jacent utiliser à partir du mime type du document.
Donc pour moi c'est toujours <emb> qu'il faut utiliser dans les textes des articles, non ?
Si ces 4 modèles ont laissé tomber des choses intéressantes figurant dans img et emb, il suffit de les reporter dans ces 4 là, mais certainement pas dans emb qui n'est là que par souci de compatibilité et s'empresse de déléguer à celui des 4 autres qui est concerné.
De ce que je comprends, la discussion porte non pas tant sur le modele technique dans lequel c'est implémenté, mais dans le service rendu par le raccourci <emb> qui a visiblement changé entre la série 1.8 et 1.9
Autrement dit, la question n'est pas de savoir comment ça marche, mais à quoi ça sert.
Il me semble dommage d'avoir perdu en diversité et restreint les possibles par défaut : <img> et <emb> se ressemblent maintenant tellement qu'il n'y a plus grand intérêt à les maintenir.
Je ne suis pas sûr de comprendre. Ces deux modèles sont de toutes façons obsolètes depuis l'introduction des filtres d'incrustation fondé sur les familles MIME, savoir audio, image, text, video cf : http://www.spip.net/fr_article3715.html
Si ces 4 modèles ont laissé tomber des choses intéressantes figurant dans img et emb, il suffit de les reporter dans ces 4 là, mais certainement pas dans emb qui n'est là que par souci de compatibilité et s'empresse de déléguer à celui des 4 autres qui est concerné.
J'ignorais cela ! Par contre, un seul raccourci d'appel serait préférable, car plus facilement mémorisable et compréhensible pour les utilisateurs, genre <emb732|video> (ou plutôt <doc732|video>) plutôt qu'une débauche de <video>, <image>, <etc>.
Je ne suis pas sur de comprendre.
les raccourcis <img> et <emb> n'ont rien d'obsolètes et restent les raccourcis documentés, voire proposés dans l'interface rédactionnelle de SPIP.
Bon, j'ai été un peu rapide, je reprends:
1. emb n'est pas obsolète pour les utilisateurs, mais techniquement ce n'est plus qu'un aiguillage, et donc si qqch ne va pas dans son rendu ce n'est pas son code qu'il faut changer mais les modèles auxquels il délègue le boulot; son code est donc gelé, ce qui est une forme d'obsolescence mais c'est vrai qu'il vaut mieux ne pas utiliser ce terme dans 2 sens différents.
2. <img> est franchement redondant avec <image>, donc obsolète. Je rappelle que cet homonyme découle d'un calcul automatique à partir de la nomenclature MIME officielle.
