Re,

Le ven. 2 août 2019 à 16:16, Charles Razack <tchar...@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' :
- ça fonctionnera avec un plugin qui crée déjà sa colonne identifiant
propre (j'ai pas regardé le code de spip pour ça) ?
- ça sera compatible avec une déclaration comme pour le plugin Pages
Uniques pour le la colonne ne soit pas créée ? Alors oui on pourrait
ajouter une sorte d'alias / surnom pour la colonne pour qu'elle prenne le
nom de page.

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 :
- on ne fait rien, il vit sa vie indépendamment
- Identifiants crée la colonne identifiant et on créer un mécanisme d'alias
de colonne avec une balise #PAGE et un critère en HTML et juste un
renommage pour le PHP (accès SQL) ?
- ou on complexifie Identifiants pour définir le "vrai" nom de la colonne
identifiant via un pipeline ou autre.

C'est du brut de réflexion ;-)

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

Répondre à