r13390 - branches/spip-2.0/ecrire/public spip/ecrire/public

Author: esj@rezo.net
Date: 2008-12-05 22:17:40 +0100 (ven, 05 déc 2008)
New Revision: 13390

Log:
Deux bugs avec les bases distantes

  * le debusqueur mettait le préfixe de table du site local quand il visualisait les requêtes sur le site distant

  * la balise LOGO_DOCUMENT ne savait pas calculer la vignette d'un document distant. En prime, dans le cas d'une balise A à produire, elle rajoute à présent un attribut Title si les champs TITRE ou DESCRIPTIF du document sont présents (la bardée d'icones semblables en rang d'oignons, c'était insupportable).

Modified:
   branches/spip-2.0/ecrire/public/debug.php
   branches/spip-2.0/ecrire/public/quete.php
   spip/ecrire/public/debug.php
   spip/ecrire/public/quete.php

Details: http://trac.rezo.net/trac/spip/changeset/13390

Coucou,

esj@rezo.net a écrit :

* la balise LOGO_DOCUMENT ne savait pas calculer la vignette d'un document distant. En prime, dans le cas d'une balise A à produire, elle rajoute à présent un attribut Title si les champs TITRE ou DESCRIPTIF du document sont présents (la bardée d'icones semblables en rang d'oignons, c'était insupportable).
  

Plusieurs remarques :
- l'utilisation des title et alt est sujet à de nombreuses discussions qui doit prendre en compte les besoins d'accessibilité
- de ce fait, notamment, les title doivent toujours être limités à 80 caractères
- dans le commit, le title généré utilise le titre et le descriptif non formatés, donc avec les raccourcis typos éventuels, et le contenu n'est pas tronqué
- le mouvement général est de supprimer au maximum la génération de html par le php du core au profit des squelettes et modeles, et là j'ai l'impression qu'on va dans l'autre sens
- le contenu que tu proposes pour le title par défaut n'est pas de manière évidente ce qui devrait être par défaut si le noyau doit vraiment proposer un title par défaut. Le type et la taille du document (comme dans le modèle doc.html) sont des infos essentielles en cas de lien (pour éviter d'envoyer l'internaute vers un document trop gros ou qu'il ne pourra pas ouvrir)
- si je ne m'abuse, cette insertion concerne la syntaxe du type [(#LOGO_DOCUMENT|#URL_DOCUMENT)]. Je pense que ton besoin se traite facilement dans le squelette par [(#LOGO_DOCUMENT|#URL_DOCUMENT|inserer_attribut{title,#TITRE|concat{#DESCRIPTIF}})]

Tout ça pour expliquer que je ne suis pas vraiment d'accord avec cet ajout a la veille de la sortie de la version stable :stuck_out_tongue:
Cédric

Le 5 déc. 08 à 22:52, cedric.morin@yterium.com a écrit :

Coucou,

esj@rezo.net a écrit :

* la balise LOGO_DOCUMENT ne savait pas calculer la vignette d'un document distant. En prime, dans le cas d'une balise A à produire, elle rajoute à présent un attribut Title si les champs TITRE ou DESCRIPTIF du document sont présents (la bardée d'icones semblables en rang d'oignons, c'était insupportable).

Plusieurs remarques :

Tant que ça !

Je pense que ton besoin se traite facilement dans le squelette par [(#LOGO_DOCUMENT|#URL_DOCUMENT|inserer_attribut{title,#TITRE|concat{#DESCRIPTIF}})]

Oui en effet. Mais si on recourt à cet argument, alors on peut dire que TOUTES les balises de SPIP ne servent à rien, puisqu'on peut toujours s'en sortir en appliquant une suite de filtres ad hoc sur un champ de table SQL. D'ailleurs j'en suis tellement convaincu que je crois bien n'avoir JAMAIS défini une balise en SPIP, seulement généraliser des balises existantes. Si j'interviens exceptionnement dans ce fichier, c'est que je dois avoir des raisons.

l'utilisation des title et alt est sujet à de nombreuses discussions qui doit prendre en compte les besoins d'accessibilité

Et bien justement, cette balise que je n'ai pas inventée ne respecte pas les critères d'accessibilité puisqu'elle produit un IMG sans Alt entouré d'un A qui n'avait meme pas de title. A défaut d'un modèlé, qui serait mieux mais mal venu dans une RC, ce petit ajout remédiait à la situation sans risque.

Le type et la taille du document sont des infos essentielles (pour éviter d'envoyer l'internaute vers un document trop gros ou qu'il ne pourra pas ouvrir); dans le commit, le title généré utilise le titre et le descriptif non formatés, donc avec les raccourcis typos éventuels, et le contenu n'est pas tronqué

Ca c'est plus jute comme critique, mais le title me parait vraiment indispensable. Je propose title+type+taille, la troncature à 80 caractère devrait ne rien perdre et tout le monde sera content.

Emmanuel

Committo,Ergo:sum a écrit :

Le 5 déc. 08 à 22:52, cedric.morin@yterium.com a écrit :

Coucou,

esj@rezo.net a écrit :

* la balise LOGO_DOCUMENT ne savait pas calculer la vignette d'un document distant. En prime, dans le cas d'une balise A à produire, elle rajoute à présent un attribut Title si les champs TITRE ou DESCRIPTIF du document sont présents (la bardée d'icones semblables en rang d'oignons, c'était insupportable).

Plusieurs remarques :

Tant que ça !

faut bien s'occuper :stuck_out_tongue:

Ca c'est plus jute comme critique, mais le title me parait vraiment indispensable. Je propose title+type+taille, la troncature à 80 caractère devrait ne rien perdre et tout le monde sera content.

type+taille+title alors, pour être sur que le type et la taille seront toujours la
ou title tronqué+type+taille pour que le tout reste dans la longueur de 80 caractères.

Ce sera une valeur par défaut suffisamment générique et acceptable, qu'on pourra au pire virer via un inserer_attribut{}
Cédric