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à.

Le 02/08/2019 à 10:09, Eric Lupinacci a écrit :
> 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 ?
>
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.

L'idée était de pouvoir récupérer l'identifiant de n'importe quel objet
(dans une boucle ou en dehors), mais il y a déjà une fonction pour ça,
inutile d'avoir une balise superflue.

>  
>
>     > 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.

À priori le fonctionnement de compositions me semble plus simple : la
colonne serait ajoutée sur toutes les tables, indépendamment de la config.
Et la configuration par objet ne servirait qu'à activer/désactiver le
champ dans les formulaires d'édition (ou en dehors).

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 ».

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,
)


Attachment: pEpkey.asc
Description: application/pgp-keys

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à