Autant pour moi,
chemin_image ne passe plus en effet par find_in_path() (cf. version commentée).
Je me dis qu’il faudrait alors une fonction chemin_image_path (peut être un nom meilleur à trouver) qui recherche d’abord une icône via chemin_image si elle existe, sinon qui regarde avec find_in_path de manière classique.
Il me semble qu’une telle fonction serait utile à plusieurs plugins (en vrac par exemple saisies, composition, noizetier, ieconfig, inserer_modeles, …), notamment pour assurer la transition entre spip 2.1 et 3.
Faudrait-il alors déclarer cette fonction dans chaque plugin qui en aurait besoin (et donc en la dupliquant) ou bien pourrait-on l’intégrer au core ?
Cordialement
Joseph
Si une fonction sert juste à assurer du support de vieux code, c’est dans le grenier qu’elle a sa place. Aux plugins qui en ont besoin de faire le necessite dans ce cas.
Sur le cas présent je suis vraiment pas convaincu de la pertinence.
Cédric
Pas forcément que du support de vieux code. Je vais prendre un cas concret : définir l’icône d’une composition ou d’une noisette. Jusqu’à présent, on attendait le chemin complet de l’icône. Mais avec le passage à SPIP 3, nombre d’icônes sont désormais dans prive/themes/spip/images. De là, 3 possibilités :
- On maintient l’existant ==> pour les icônes dispo dans un thème du privé, il faut alors les déclarer comme : ‘prive/themes/spip/images/icon.png’ (mais on perd la config de thème de l’utilisateur)
- On impose l’utilisation d’icônes provenant d’un thème du privé qu’on récupère avec chemin_image. C’est logique ==> toutes les icônes d’interface sont alors rangées au même endroit. Par contre, peut être moins intuitif pour quelqu’un qui définit ses compositions ou noisettes personnelles dans le dossier squelette. Quoi que…
- On permet les deux via une fonction chemin_image_path (bref celle évoquée là).
Cordialement
Joseph
Il me semble que le icones de composition par exemple n’ont rien à faire dans le thème de l’espace privé. Même si elles s’affichent dans l’espace privé, ce sont des icones du squelette, qui ont à voir avec le public, et n’ont pas de raison de changer en fonction des préférences des utilisateurs. Je sais qu’on est à la frontière (ou à l’intersection) entre les deux espaces, mais ça me semble le plus cohérent.
Et du coup #CHEMIN suffit ici.
Le 16 avr. 2012 à 10:46, Joseph a écrit :
Le 16 avril 2012 10:13, cedric.morin@yterium.com <cedric.morin@yterium.com> a écrit :
Si une fonction sert juste à assurer du support de vieux code, c’est dans le grenier qu’elle a sa place. Aux plugins qui en ont besoin de faire le necessite dans ce cas.
Pas forcément que du support de vieux code. Je vais prendre un cas concret : définir l’icône d’une composition ou d’une noisette. Jusqu’à présent, on attendait le chemin complet de l’icône. Mais avec le passage à SPIP 3, nombre d’icônes sont désormais dans prive/themes/spip/images. De là, 3 possibilités :
- On maintient l’existant ==> pour les icônes dispo dans un thème du privé, il faut alors les déclarer comme : ‹ prive/themes/spip/images/icon.png › (mais on perd la config de thème de l’utilisateur)
- On impose l’utilisation d’icônes provenant d’un thème du privé qu’on récupère avec chemin_image. C’est logique ==> toutes les icônes d’interface sont alors rangées au même endroit. Par contre, peut être moins intuitif pour quelqu’un qui définit ses compositions ou noisettes personnelles dans le dossier squelette. Quoi que…
- On permet les deux via une fonction chemin_image_path (bref celle évoquée là).
Cordialement
Joseph
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
On est vraiment à la frontière. Il y a aussi que, au moins dans ma pratique personnelle, je mutualise des icônes. Par exemple, je vais reprendre l’icône d’agenda pour ma composition article-agenda par exemple, une icône du plugin contact avancé pour la composition article-contact etc. Cela permet d’utiliser facilement des icônes existantes et cohérentes, le cas échéant, avec les autres éléments de l’espace privé.
Composition est vraiment à la frontière. Mais sur des plugins comme Menus ou bien comme le noiZetier, il est logique dans certains cas de reprendre les icônes de certains objets. Ma noisette liste d’articles va reprendre l’icône des articles et ma liste de brèves l’icône des brèves.
D’où peut-être une approche combinée où les deux déclarations sont possibles.
Joseph
Le 19 avril 2012 10:49, Cédric Morin <cedric.morin@yterium.com> a écrit :
Il me semble que le icones de composition par exemple n’ont rien à faire dans le thème de l’espace privé. Même si elles s’affichent dans l’espace privé, ce sont des icones du squelette, qui ont à voir avec le public, et n’ont pas de raison de changer en fonction des préférences des utilisateurs. Je sais qu’on est à la frontière (ou à l’intersection) entre les deux espaces, mais ça me semble le plus cohérent.
Et du coup #CHEMIN suffit ici.
Le 16 avr. 2012 à 10:46, Joseph a écrit :
Le 16 avril 2012 10:13, cedric.morin@yterium.com <cedric.morin@yterium.com> a écrit :
Si une fonction sert juste à assurer du support de vieux code, c’est dans le grenier qu’elle a sa place. Aux plugins qui en ont besoin de faire le necessite dans ce cas.
Pas forcément que du support de vieux code. Je vais prendre un cas concret : définir l’icône d’une composition ou d’une noisette. Jusqu’à présent, on attendait le chemin complet de l’icône. Mais avec le passage à SPIP 3, nombre d’icônes sont désormais dans prive/themes/spip/images. De là, 3 possibilités :
- On maintient l’existant ==> pour les icônes dispo dans un thème du privé, il faut alors les déclarer comme : ‹ prive/themes/spip/images/icon.png › (mais on perd la config de thème de l’utilisateur)
- On impose l’utilisation d’icônes provenant d’un thème du privé qu’on récupère avec chemin_image. C’est logique ==> toutes les icônes d’interface sont alors rangées au même endroit. Par contre, peut être moins intuitif pour quelqu’un qui définit ses compositions ou noisettes personnelles dans le dossier squelette. Quoi que…
- On permet les deux via une fonction chemin_image_path (bref celle évoquée là).
Cordialement
Joseph
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone