J'ai quelques limitations avec la gestion des S finaux entre les noms
de tables et les nom_objets mais bon je creuserai ca un tout petit peu
après.
Oui, pour moi c'est vraiment *la* fausse bonne idée de SPIP, ces
subtilités de singulier/pluriel.
C'est grammaticalement correct, c'est soi-disant plus intuitif, mais au
final je pense que ça embrouille plus de monde, autant utilisateurs que
développeurs, que ça n'en aide, en plus d'ajouter des mécanismes lourds
au code de SPIP lui-même. Résultat, la fameuse Courbe d'Apprentissage,
grande fierté ou en tout cas grand objectif de SPIP, en prend un sacré
coup. Je ne compte plus les personnes, moi compris, qui se sont pris
les pieds dans ce tapis-là, de manière plus ou moins insistante,
hébétée, et variée.
Au risque d'une entorse à la beauté littéraire, je suis complètement
partisan d'une *invariabilité* des objets:
- tables: spip_article, spip_groupe_mots
- champs: id_article, id_groupe_mots
- BOUCLE_xx(ARTICLE), BOUCLE_yy(GROUPE_MOTS)
- etc.
Ça va faire bizarre à accepter pour les gens qui parlent déjà SPIP
couramment, mais qu'est-ce que ça va soulager le core, la zone, les
utilisateurs... et les formateurs !
(Je réponds sur spip-zone mais mets spip-dev en copie, car c'est plutôt
une discussion sur le core.)
Bof, pour les utilisateurs finaux de ces notions là, c'est-à-dire pas ceux de l'interface mais ceux qui écrivent des squelettes, c'est effectivement plus intuitif quand on garde le singulier/pluriel puisqu'on fait une boucle pour récupérer DES articles, mais on demande l'identifiant d'UN article, etc.
Là où c'est plus complexe effectivement, c'est pour les développeurs. Si tu formes des développeurs, oui c'est plus long. Mais :
1) ça ne concerne qu'une minorité de gens
2) il y a toute une série de fonctions SPIP entièrement dédiées à la bonne gestion de la différence "nom de la table" / "nom de l'objet seul" / "nom de la clé primaire".
Il ne faut plus JAMAIS ajouter ou enlever un "s" à la main à un mot. Il y a des fonctions pour ça, afin de déclarer quel est le singulier et le pluriel. Ce qui fait d'ailleurs qu'il peut y avoir "spip_jeux" et "id_jeu" sans hack pourri.
Bof, pour les utilisateurs finaux de ces notions là, c'est-à-dire pas
ceux de l'interface mais ceux qui écrivent des squelettes, c'est
effectivement plus intuitif quand on garde le singulier/pluriel
puisqu'on fait une boucle pour récupérer DES articles, mais on
demande l'identifiant d'UN article, etc.
Bien sûr, c'est le but de l'existence de ces deux formes.
Mais dans ma (petite) expérience avec des nouveaux venus dans
l'écriture de squelettes, malgré la logique apparente du truc, j'ai
souvent constaté qu'au final les débutants ne sont pas sûrs de la forme
à utiliser, et se plantent souvent.
Ceci dit, je suis effectivement curieux d'avoir des retours de gens qui
sont souvent face à des débutants. Je suis peut-être seul (ou un des
seuls) à trouver que les gens se mélangent les pinceaux.
2) il y a toute une série de fonctions SPIP entièrement dédiées à la
bonne gestion de la différence "nom de la table" / "nom de l'objet
seul" / "nom de la clé primaire".
Oui, et c'est tout ce pan-là qui pourrait disparaître si on s'en tenait
à une seule forme. C'est pour ça que je parlais de simplification du
code de SPIP lui-même, et d'une simplification pour les développeurs
car cette série de fonctions représente encore une autre facette de la
programmation avec SPIP à apprendre.
En résumé, les deux intentions que je vois à cette distinction
singulier/pluriel, c'est :
1. la satisfaction intellectuelle du point de vue grammatical ;
2. une syntaxe plus simple d'apprentissage pour les nouveaux.
Le premier point me semble superflu, surtout s'il en coûte la
complexité évoquée plus haut ; quand au second, je le trouve tellement
discutable qu'à mon avis c'est même l'effet contraire qui est produit.