Holla,
il existe un plugin "identifiant" permettant d'affecter un identifiant uniquement à des objets.
Il existe le plugin "page unique" qui donne aussi des identifiants aux pages (article hors rubrique), mais sans passer par ce plugin.
J'aurais besoin d'avoir une interface uniforme lorsqu'on donne un identifiant, que ce soit pour un article ou une page.
Que pensez vous de modifier page unique pour que, sur ce point, il s'appuie sur le plugin "identifiant".
Maïeul
Maïeul a écrit le 30/07/2019 à 16:26 :
Holla,
il existe un plugin "identifiant" permettant d'affecter un identifiant uniquement à des objets.
Il existe le plugin "page unique" qui donne aussi des identifiants aux pages (article hors rubrique), mais sans passer par ce plugin.
J'aurais besoin d'avoir une interface uniforme lorsqu'on donne un identifiant, que ce soit pour un article ou une page.
Que pensez vous de modifier page unique pour que, sur ce point, il s'appuie sur le plugin "identifiant".
Je suis pour !
C'est donc Plugin Identifiants - SPIP-Contrib
PS : Et ça permet de mettre un identifiant sur un documents ?
--
RealET
Hello,
Moué, moi je freine plutot des 4 fers parce que vlà les embuches et les sites cassés si on passe d’un champ dans la table articles vers un champ dans une autre table avec un lien…
(ou alors avant d’écrire la moindre ligne de code merci de recenser les boucles et usages pour être sur qu’on ne casse aucun squelette à l’arrivée…)
--
Cédric
Le 30 juil. 2019 à 16:27 +0200, Maïeul <maieul@maieul.net>, a écrit :
Holla,
il existe un plugin "identifiant" permettant d'affecter un identifiant
uniquement à des objets.Il existe le plugin "page unique" qui donne aussi des identifiants aux
pages (article hors rubrique), mais sans passer par ce plugin.J'aurais besoin d'avoir une interface uniforme lorsqu'on donne un
identifiant, que ce soit pour un article ou une page.Que pensez vous de modifier page unique pour que, sur ce point, il
s'appuie sur le plugin "identifiant".Maïeul
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Le 30/07/2019 à 16:56, Eric Lupinacci a écrit :
Le plugin Identifiant crée une table de lien et donc j'ai eu peur de rajouter de la complexité (jointure) pour juste un champ supplémentaire.
En outre, comme je ne voulait pas que ce champ apparaisse pour tous les groupes j'ai pas creusé plus loin.J'ai peut-être eu tort et qu'il faudrait que je migre vers ce plugin ?
Faudrait que Rasta nous donne son avis.++
Eric
Hello,
À l'époque j'étais partagé entre 2 options : ajouter un champ « identifiant » sur toutes les tables comme le fait compositions, ou utiliser une table de liens.
Maintenant avec du recul, j'aurais envie de repartir sur la 1ère option, ça ne me semble pas idéal de provoquer une jointure juste pour un champ.
Sur ce point là, je suis preneur de vos avis/retours.
Je crois que rasta était plutôt ouvert à l'idée d'interfacer les plugins nécessitant des identifiants avec ce plugin (pages uniques, formidable, etc.). Mais sur ce point il reste encore des choses à faire je crois.
Par exemple dans pages uniques, le champ utilisé est "page" au lieu de "identifiant", donc il faut sans doute un moyen aux plugin de déclarer ces exceptions pour chaque table.
(nb : il est dans la pampa en ce moment).
mouais, effectivement.
c'est problématique. Est-ce qu'on pourrait peut être imaginer une autre
implémentation d'identifiant (autre plugins) qui au lieu d'une table
avec jointurer crée simplement le champ sur n'importe quel objet ?
Le mardi 30 juillet 2019 à 17:18 +0200, Cerdic a écrit :
Moué, moi je freine plutot des 4 fers parce que vlà les embuches et
les sites cassés si on passe d’un champ dans la table articles vers un
champ dans une autre table avec un lien…(ou alors avant d’écrire la moindre ligne de code merci de recenser
les boucles et usages pour être sur qu’on ne casse aucun squelette à
l’arrivée…)--
Le 30/07/2019 à 17:21, Charles Razack a écrit :
Sur ce point là, je suis preneur de vos avis/retours.
Je crois que rasta était plutôt ouvert à l'idée d'interfacer les plugins
nécessitant des identifiants avec ce plugin (pages uniques, formidable,
etc.). Mais sur ce point il reste encore des choses à faire je crois.
Par exemple dans pages uniques, le champ utilisé est "page" au lieu de
"identifiant", donc il faut sans doute un moyen aux plugin de déclarer
ces exceptions pour chaque table.
(nb : il est dans la pampa en ce moment).
Yep, moi j'ai plutôt l'avis effectivement que ça devrait être un champ
dans chaque table, et que ça devait détecter magiquement les objets qui
prévoient déjà ce champ, et ne les ajouter que pour ceux qui ne l'ont
pas déjà (et ne pas le supprimer à la désinstallation pour ceux qui
l'avaient déjà évidemment).
Par ailleurs, dans la déclaration des objets, on pourrait ajouter une
déclaration "identifiant" pour dire quel champ est l'identifiant unique
de l'objet si on veut en déclarer un autre que "identifiant". Ce qui
permettrait par exemple de déclarer "identifiant" => "page". Enfin c'est
une idée rapidos hein…
Le plugin Identifiants ajouterait une interface dès qu'un objet a ce
champ, qu'il soit détecter magiquement, ou déclaré explicitement, ou
ajouté par config du plugin lui-même.
Par ailleurs, comme ça serait toujours un champ direct de la table,
l'interface devrait à mon avis être dans le formulaire d'édition de
l'objet, et non pas dans un énième bloc sur la vue.
--
RastaPopoulos
Yep, moi j'ai plutôt l'avis effectivement que ça devrait être un champ
dans chaque table, et que ça devait détecter magiquement les objets qui
prévoient déjà ce champ, et ne les ajouter que pour ceux qui ne l'ont
pas déjà (et ne pas le supprimer à la désinstallation pour ceux qui
l'avaient déjà évidemment).Par ailleurs, dans la déclaration des objets, on pourrait ajouter une
déclaration "identifiant" pour dire quel champ est l'identifiant unique
de l'objet si on veut en déclarer un autre que "identifiant". Ce qui
permettrait par exemple de déclarer "identifiant" => "page". Enfin c'est
une idée rapidos hein…Le plugin Identifiants ajouterait une interface dès qu'un objet a ce
champ, qu'il soit détecter magiquement, ou déclaré explicitement, ou
ajouté par config du plugin lui-même.Par ailleurs, comme ça serait toujours un champ direct de la table,
l'interface devrait à mon avis être dans le formulaire d'édition de
l'objet, et non pas dans un énième bloc sur la vue.
Je suis parfaitement d'accord sur tout ca. La question est donc : qu'est-ce qu'on fait du plugin actuel ? On le laisse tomber et on crée un autre ex nihilo, avec un autre titre ? on le fait évoluer en assurant une migration + retrocompatibilité des critères ?
Hello,
Le 01/08/2019 à 20:55, Eric Lupinacci a écrit :
Je ne pense pas qu'il faille abandonner le plugin actuel car le nouveau rendrait exactement le même service.
+1
A mon avis il faut faire une nouvelle branche 2.0 puisque la version actuelle est la 1.1.14.
La question que je me pose c'est : faut-il activer par défaut à l'upgrade le script de migration table identifiants vers colonne identifiant pour les objets concernés ou le déclencher sur demande ?Comme il y a peu de sites qui l'utilise (14 d'après Plugins SPIP et 28 d'après les manifestants) je ne suis pas sur qu'il faille assurer une retro-compatiblité des critères : il suffira pour les sites utilisateurs de modifier les quelques boucles concernées.
Ça, c'est présumer que les gens qui utilisent le plugin lisent tous les mails des listes, les commits détaillés, tout ça.
Vu qu'il n'y a aucune info qui s'affiche dans SVP quand un plugin est mis à jour (sur une version majeure ou pas), je trouve ça un peu violent.
Pour moi, il faut _toujours_ faire le travail nécessaire pour éviter une rupture de compatibilité.
Par contre, dans cette nouvelle version comment compte-t-on créer la colonne additionnelle ? A la demande pour un type d'objet ou pour tous les types d'objet présents à l'instant de l'installation ?
Le plugin actuel propose une configuration pour choisir les objets, comme Rang par exemple.
Ça me parait une bonne pratique, pour éviter de surcharger l'interface avec des champs de saisie techniques là où on en a pas besoin.
Les deux points ci dessus, pour moi ça consiste à penser aux utilisateurs d'abord, quels que soient leurs profils.
C'est important.
--
nicod_
Hello,
Le ven. 2 août 2019 à 01:30, nicod_ <nicod@lerebooteux.fr> a écrit :
Comme il y a peu de sites qui l’utilise (14 d’après Plugins SPIP et 28
d’après les manifestants) je ne suis pas sur qu’il faille assurer une
retro-compatiblité des critères : il suffira pour les sites utilisateurs
de modifier les quelques boucles concernées.Ça, c’est présumer que les gens qui utilisent le plugin lisent tous les
mails des listes, les commits détaillés, tout ça.
Vu qu’il n’y a aucune info qui s’affiche dans SVP quand un plugin est
mis à jour (sur une version majeure ou pas), je trouve ça un peu violent.
Pour moi, il faut toujours faire le travail nécessaire pour éviter une
rupture de compatibilité.
Ouais c’est mieux. Après faut voir si cela en vaut la chandelle.
Je suis pas fan des compatibilités éternelles qui rendent le code illisible surtout plusieurs années plus tard.
Après, j’ai regardé rapidement le code du plugin, qui est assez important justement à cause de la table de liens qui va disparaître.
Passer à une colonne identifiant va énormément simplifier le code et éliminer la balise #IDENTIFIANT qui est calculée.
Si la balise est déjà utilisée dans une boucle de l’objet concerné ça devrait être indolore car l’appel est surement fait sans argument (on prend le contexte) mais si il y a des arguments il va falloir conserver une balise chelou qui surcharge la colonne dans ce cas.
Si c’est un accès SQL en php, comme il n’existe pas d’API du type identifiant_lire($objet, $id_objet) ça risque d’être difficile pour la compatibilité car il faudra bien changer la requête non ?
Par contre, dans cette nouvelle version comment compte-t-on créer la
colonne additionnelle ? A la demande pour un type d’objet ou pour tous
les types d’objet présents à l’instant de l’installation ?Le plugin actuel propose une configuration pour choisir les objets,
comme Rang par exemple.
Ça me parait une bonne pratique, pour éviter de surcharger l’interface
avec des champs de saisie techniques là où on en a pas besoin.
Oui ça je sais mais dans la version actuelle tout était géré dans une table de liens, donc rien de plus facile quand on voulait supprimer l’utilisation de l’identifiant : on supprimait les lignes.
Là si tu choisis d’utiliser l’identifiant en cochant la case pour un type d’objet, si on décoche cette case que fait-on ?
A priori on vire pas la colonne, on la neutralise ?
C’est juste une interrogation, rien de plus.
Après pour mon besoin personnel sur SVP typologie, j’utilise la colonne identifiant pour les mots-clés mais uniquement ceux qui sont dans un groupe donné.
Pour utiliser cette nouvelle version il faudrait que je puisse autoriser ou pas utilisation en visu et édition.
Faudrait vérifier que les autorisations existent et ainsi peuvent être surchargées.
++
Eric
Le 02/08/2019 à 10:09, Eric Lupinacci a écrit :
Pour moi, il faut _toujours_ faire le travail nécessaire pour éviter
une
rupture de compatibilité.Ouais c'est mieux. Après faut voir si cela en vaut la chandelle.
Oui, d'autant que je fais le malin et que je viens ramener ma fraise, mais que c'est pas moi qui vais faire le boulot 
Conseilleurs pas payeurs, tout ça 
--
nicod_
Je ne vois non plus aucune raison de créer un nouveau plugin qui aurait la même finalité.
Une branche v2, avec dans la mesure du possible une migration pour les utilisateurs de la v1, et voilà.
Re,
Le ven. 2 août 2019 à 16:16, Charles Razack <tcharlss@bravecassine.com> a écrit :
Je ne vois non plus aucune raison de créer un nouveau plugin qui aurait la même finalité.
Une branche v2, avec dans la mesure du possible une migration pour les utilisateurs de la v1, et voilà.
Ok ça c’est fait. J’ai créé une branche v2.
La balise #IDENTIFIANT est prévue pour fonctionner avec et sans argument.
Mais quitte à changer de branche, je pense que la balise peut être tout simplement supprimée.
Je n’ai pas vu d’utilisation sur la zone avec les arguments.
Si on peut simplifier et abandonner cette utilisation c’est mieux je pense.
À priori le fonctionnement de compositions me semble plus simple : la colonne serait ajoutée sur toutes les tables, indépendamment de la config.
Soit mais la déclaration de compositions est :
$tables[]['field']['composition'] = "varchar(255) DEFAULT '' NOT NULL";
On est sur que dans le cas d’Identifiants qui créerait des colonne ‹ identifiant › :
Maintenant, je me dis un truc : les plugins qui utilisent une colonne identifiant ne devrait-il pas utiliser Identifiants plutôt que de faire des contorsions dans Identifiants ?
Et la configuration par objet ne servirait qu’à activer/désactiver le champ dans les formulaires d’édition (ou en dehors).
Oui soit.
Ensuite bonne question: quand on décoche un type d’objet, est-ce qu’on doit supprimer tous les identifiants associés ?
Le problème est le même qu’ils soient enregistrés dans une table de liens ou pas d’ailleurs.
Il pourrait s’agir d’une case à cocher supplémentaire : « supprimer les identifiants inutilisés ».
A priori si on neutralise l’utilisation de la colonne dans l’affichage et l’édition ça ne devrait pas être nécessaire. Le seul moment où on vire tout c’est la désinstallation du plugin non ?
Autre question : pour certains objets, les identifiants peuvent être obligagoires et ne doivent pas pouvoir être désactivés : pages uniques par exemple.
Est-ce qu’on considère que quand un plugin déclare son champ « identifiant » dans la déclaration de l’objet, ça veut dire qu’il est obligatoire ?
Ou est-ce que ce serait une précision supplémentaire ? Par exemple :‹ identifiant › => array(
‹ champ › => ‹ page ›,
‹ obligatoire › => true,
)
L’intérêt de la table de liens actuel c’est que tu peux savoir simplement qu’une table à déjà une colonne identifiant via la fonction lister_tables_objets_sql() . Si on utilise le pipeline de déclaration des objets SQL pour créer la colonne dans les objets comment on va savoir si elle existait avant ou pas ? D’ailleurs je me suis toujours posé cette question de comment connaitre la liste originelle des champs d’une table ?
C’est pourquoi j’en reviens au point sur la déclaration similaire à Compositions.
Ne faudrait-il pas simplement migrer les plugins qui le nécessitent sous Identifiants (y en a peu a priori).
Le cas de Pages Uniques qui utilise une colonne page est plus complexe.
On a plusieurs solutions :
C’est du brut de réflexion 
++
Eric
Rere,
Autre question : pour certains objets, les identifiants peuvent être obligagoires et ne doivent pas pouvoir être désactivés : pages uniques par exemple.
Est-ce qu’on considère que quand un plugin déclare son champ « identifiant » dans la déclaration de l’objet, ça veut dire qu’il est obligatoire ?
Ou est-ce que ce serait une précision supplémentaire ? Par exemple :‹ identifiant › => array(
‹ champ › => ‹ page ›,
‹ obligatoire › => true,
)
Je reviens sur ce sujet après un peu de réflexion.
J’ai l’impression que le plus simple est d’utiliser un pipeline pour déclarer, pour les tables qui le nécessitent, un identifiant qui fait déjà partie de la déclaration originelle mais dont on voudrait qu’il soit géré par Identifiant (si j’ai bien compris).
La déclaration pourrait être :
‹ article › => array(‹ identifiant › => ‹ nom de la colonne identifiant ›);
La question que je me pose c’est ne faut-il pas séparer cette déclaration du pipeline declarer_tables_objets_sql
et plutôt utiliser un pipeline spécifique du type declarer_identifiant_objets_sql pour ne pas risquer des effets de bord futurs sachant que l’API objet est dans SPIP et peut évoluer indépendamment du plugin Identifiants.
Le besoin est juste d’avoir cette liste de table ayant une identifiant déjà défini, liste qui a priori n’évoluera pas car je vois plus l’intérêt après la v2 d’en rajouter puisque Identifiants fait le travail.
Une autre chose aussi, si par exemple je reprends SVP Typologie en utilisant le plugin Identifiants pour ajouter l’identifiant aux mots-clés de cette façon, je nécessite Identifiants dans SVP Typologie. Mais, en fait, il faudrait que l’installation de SVP Typologie active automatiquement l’utilisation de l’identifiant dans la configuration d’Identifiants et que cette activation ne soit pas modifiable manuellement…
Il est temps d’arrêter pour ce soir j’ai l’impression :p.
Le 02/08/2019 à 20:58, Eric Lupinacci a écrit :
La question que je me pose c'est ne faut-il pas séparer cette
déclaration du pipeline declarer_tables_objets_sql
et plutôt utiliser un pipeline spécifique du type
declarer_identifiant_objets_sql pour ne pas risquer des effets de bord
futurs sachant que l'API objet est dans SPIP et peut évoluer
indépendamment du plugin Identifiants.
Le besoin est juste d'avoir cette liste de table ayant une identifiant
déjà défini, liste qui a priori n'évoluera pas car je vois plus
l'intérêt après la v2 d'en rajouter puisque Identifiants fait le travail.
Les champs versionables d'un objet sont propres au plugin Révisions, et
c'est bien dans la déclaration de l'objet.
Les rôles sont propres au plugin Rôles et aux plugins qui l'implémentent
(Rôles de documents, Rôles d'auteurs, etc), et c'est bien dans la
déclaration de l'objet.
Pour l'identifiant c'est pareil, il s'agit d'une caractéristique qui
défini tel ou tel objet SPIP, et c'est bien à ça que sert ce tableau
dans ce pipeline. Du coup ça me parait confus de multiplier les endroits.
Toutes les informations génériques (= qui peuvent s'appliquer à
n'importe quel objet en théorie) qui définissent comment se comportent
un objet, devraient se trouver dans sa déclaration unique.
--
RastaPopoulos
Hello,