[SPIP Zone] r113280 - _plugins_/roles_documents/trunk

rastapopoulos · Avril 16, 2019, 11:41

On discute sur la liste spip-zone, pas sur la liste des commits.

Le 16/04/2019 à 09:34, Michel Bystranowski a écrit :

En quoi sont-ils principaux ? Est-ce qu'un rôle peut être « principal »
sans être un logo ? Si oui, il manque une option pour gérer ça, et si
non, alors pourquoi ne pas dire tout de suite que c'est un logo ? Le mot
« principal » peut vouloir dire plein d'autres choses, dont aucune n'a
quoi que ce soit à voir avec des logos, c'est très confusant…

C'est peut-être pinailler, mais ce mot fait partie l'API de déclaration
de logos, c'est plus qu'un détail d'implémentation. Les dévs qui vont
s'en servir vont immanquablement perdre du temps à comprendre que
logo === principal quand on parle des rôles.
« Mal nommer les choses, c'est ajouter au malheur du monde » disait
A.Camus

Je suis d'accord que cette API est plus flexible, et peut-être aussi
plus « SPIPienne » que ce que j'avais imaginé à la base (préfixer le nom
du role avec « logo_ »), mais est-ce qu'on ne pourrait pas renommer ça ?
P.ex « roles_logos » au lieu de « roles_principaux » ?

Non, c'est justement "logo" qui ne veut rien dire. Et ce n'est pas parce
qu'il est utilisé depuis 15 ans qu'il veut dire quelque chose.

Lors d'une rencontre à Toulouse, Jacotte avait fait un retour
d'expérience en disant justement que pour quelqu'un qui n'était pas VIP
de SPIP, ce vocabulaire ne voulait pas dire grand chose. Un logo pour le
commun des mortels, c'est le logo d'une entreprise, un symbole la
plupart du temps lié à une typographie du nom de la chose dont c'est le
logo. Alors que là on parle de "l'image principale d'un contenu".

Dans WP ça s'appelle "image à la une", ce qui est déjà bien mieux que
notre "logo" au niveau sémantique, mais donc pas encore assez générique
puisque ce n'est que pour une image. D'où le concept plus général de
"documents principaux".

L'API étend ce concept de document principal, sachant que ce n'est même
pas forcément une image, donc c'est encore plus pertinent de le changer.
Il peut parfaitement y avoir un rôle "PDF principal" d'un contenu… un
rôle "Compte rendu de l'événement" pour y mettre le PDF du compte rendu
d'un événement, enfin ça peut vraiment être n'importe quoi. Et donc
aucun rapport avec un "logo".

Les rôles indiqués comme étant "principaux", signifie qu'ils sont
forcément uniques pour leur rôle précis. Il n'y a qu'un logo (image
principale), il n'y a qu'un "bandeau d'entête", etc. Du coup ces rôles
principaux sont alors affichés et éditables à part sur le côté, là où il
n'y avait que les logos avant, afin de garder cette séparation ergonomique.

--
RastaPopoulos

Michel_Bystranowski · Avril 16, 2019, 1:15

RastaPopoulos writes:

On discute sur la liste spip-zone, pas sur la liste des commits.

Le 16/04/2019 à 09:34, Michel Bystranowski a écrit :

En quoi sont-ils principaux ? Est-ce qu'un rôle peut être « principal »
sans être un logo ? Si oui, il manque une option pour gérer ça, et si
non, alors pourquoi ne pas dire tout de suite que c'est un logo ? Le mot
« principal » peut vouloir dire plein d'autres choses, dont aucune n'a
quoi que ce soit à voir avec des logos, c'est très confusant…

C'est peut-être pinailler, mais ce mot fait partie l'API de déclaration
de logos, c'est plus qu'un détail d'implémentation. Les dévs qui vont
s'en servir vont immanquablement perdre du temps à comprendre que
logo === principal quand on parle des rôles.
« Mal nommer les choses, c'est ajouter au malheur du monde » disait
A.Camus

Je suis d'accord que cette API est plus flexible, et peut-être aussi
plus « SPIPienne » que ce que j'avais imaginé à la base (préfixer le nom
du role avec « logo_ »), mais est-ce qu'on ne pourrait pas renommer ça ?
P.ex « roles_logos » au lieu de « roles_principaux » ?

Non, c'est justement "logo" qui ne veut rien dire. Et ce n'est pas parce
qu'il est utilisé depuis 15 ans qu'il veut dire quelque chose.

Lors d'une rencontre à Toulouse, Jacotte avait fait un retour
d'expérience en disant justement que pour quelqu'un qui n'était pas VIP
de SPIP, ce vocabulaire ne voulait pas dire grand chose. Un logo pour le
commun des mortels, c'est le logo d'une entreprise, un symbole la
plupart du temps lié à une typographie du nom de la chose dont c'est le
logo. Alors que là on parle de "l'image principale d'un contenu".

Dans WP ça s'appelle "image à la une", ce qui est déjà bien mieux que
notre "logo" au niveau sémantique, mais donc pas encore assez générique
puisque ce n'est que pour une image. D'où le concept plus général de
"documents principaux".

L'API étend ce concept de document principal, sachant que ce n'est même
pas forcément une image, donc c'est encore plus pertinent de le changer.
Il peut parfaitement y avoir un rôle "PDF principal" d'un contenu… un
rôle "Compte rendu de l'événement" pour y mettre le PDF du compte rendu
d'un événement, enfin ça peut vraiment être n'importe quoi. Et donc
aucun rapport avec un "logo".

Les rôles indiqués comme étant "principaux", signifie qu'ils sont
forcément uniques pour leur rôle précis. Il n'y a qu'un logo (image
principale), il n'y a qu'un "bandeau d'entête", etc. Du coup ces rôles
principaux sont alors affichés et éditables à part sur le côté, là où il
n'y avait que les logos avant, afin de garder cette séparation ergonomique.

OK, je comprends le raisonnement, c'est vrai qu'au fond le terme de
« logo » n'est pas super non plus…

J'aime bien l'idée d'étendre ce concept à tous les types de documents,
mais je pense qu'il ne faut pas pour autant abandonner l'idée que
certains rôles doivent pouvoir être restreints aux images. On devrait
pouvoir implémenter le mécanisme des « logos » historiques de SPIP avec
la nouvelle API. Pour ne pas perdre en fonctionnalités mais aussi pour
garder la compatibilité avec les sites existants.

En l'état actuel des choses, quand j'installe roles_documents, je peux
ensuite uploader un pdf comme logo, alors que ça n'est prévu dans aucun
squelette. Ça correspond pourtant à un besoin qui revient tout le temps,
il faut pouvoir associer des visuels aux contenus, et le créateur des
squelettes a besoin d'être confiant que l'interface privée ne va pas
permettre d'encoder des contenus qui ne s'affichent pas bien.

En pensant plus général, ce problème risque de se produire avec les
autres types de documents aussi. Pour reprendre ton exemple de compte
rendu d'événement en pdf, le concepteur du site peut vouloir l'afficher
dans un cadre pdf.js sur le site et voudra alors s'assurer qu'on ne
mette pas une vidéo qui fera planter le bazar. Ou alors si je crée un
rôle principal « version audio » pour y mettre des versions lues à haute
voix de chaque article, je ne veux pas qu'on puisse y mettre un jpeg qui
viendra faire planter le beau podcast que je génère avec ça…

Et en sur-généralisant, je me dit que c'est peut-être valable pour tous
les rôles de document, et pas seulement les principaux. Au fond si je
donne un rôle à un document c'est pour en faire quelque chose, et ce
« faire quelque chose » demande la plupart du temps que le document soit
d'un type bien particulier.

Pour remédier à ça, on pourrait p.ex. rajouter une clé « extensions » au
tableau « roles_objets », pour spécifier ce qu'on veut comme type de
documents :

'roles_objets' => array(
    '*' => array(
        'choix' => array('document', 'logo', 'version_lue'),
        'defaut' => 'document',
        'principaux' => array('logo', 'version_lue'),
        'extensions' => array(
            'document' => '*',
            'logo' => array('jpg', 'jpeg', 'png'),
            'version_lue' => array('mp3', 'wav', 'aiff'),
       )
    )
)

On pourrait ensuite s'arranger pour que les formulaires d'édition de
logos et d'attribution des rôles prennent ça en compte.

Qu'en pensez-vous ?