MARNE Bertrand a écrit :
le probleme n'est pas le nommage de la table mais que 2 champs d'une
meme table ne peuvent pas avoir le meme nom.
la convention de nommage de Spip pour les relation n<->n est la suivante :
table 1 : spip_xxx (id_xxx, .... reste des champs)
table 2 : spip_yyy (id_yyy, .... reste des champs)
table de jointure : spip_xxx_yyy (id_xxx, id_yyy)
on ne peut donc pas associer une table à elle meme avec ce principe (on
pourra sans doute quand on aura des "alias", mais ca implique quand meme
de donner un sens à la relation, X,Y etant different de Y,X => relation
parent/enfant et non pas simple association).
Ne peut-on pas déroger à cette convention de nommage en créant, par
exemple, une jointure nommée «spip_mot_mot_parent» (et donc si je
comprends bien un critère «id_mot_parent» pour les boucles MOTS) ?
non, non, le probleme n'est pas vraiment la.
le gestion des mots clés est "generique" (c'est le travail que j'ai fait sur ce plugin).
le principe est justement de s'appuyer sur la convention de nommage existante pour avoir des fonctionnalités qui marchent sur n'importe quelle table, pour peu qu'on respecte cette fameuse convention.
j'ai mis ca en place pour spipcarto initialement.
Il y a dans la gestion des mots clés de spip des "if table=breves", if table=articles ...
au lieu d'ajouter des ifs à chaque fois, on s'appuie directement sur les parametres, du coup, il suffit de "dire" à spip (en declarant une "chose_possible") qu'il y a des mots sur un type d'objet pour pouvoir utiliser la "boite" d'affectation, les criteres id_mots, type_mot, titre_mot...
1) pour affecter un mot clé, on passe le type d'objet sur lequel on affecte, l'id de l'objet et l'id du mot
pour les mots, ca donnerait donc type=mot&id_mot=X&id_mot=Y
dans le traitement, on ne récupèrerait que X OU Y, impossible d'avoir X ET Y
2) <BOUCLE_X(XXXS){id_mot=X}> est traduit par spip par une jointure sur la table spip_mots_xxx pour remonter tous les XXX ayant le mot X affecté.
mais <BOUCLE_MOT(MOTS){id_mot=X}>, c'est traduit par je veux LE mot dont l'id est X
3) comme je le disais, on ne peut pas avoir 2 champs de meme nom dans une table, or le repérage des jointure par Spip s'appuie sur la correspondance entre le nom de la clé primaire et le nom du champ dans la table de jointure
bref, pour pouvoir le faire, il faudrait
1- changer le systeme d'affectation des mots clé (en passant par exemple id_mot_lie au lieu de id_mot).
ca n'est pas le plus difficile, mais il y a peut etre des consequences importantes (pas trop sur spip lui meme normalement, mais par contre, ca risque de rendre le plugin incompatible avec d'autres qui exploiterait la gestion des mots clés)
2- traiter au moins un critere specifique pour pouvoir faire <BOUCLE_MOT(MOTS){id_mot=X}{id_mot_lie=Y}> et que spip ne se melange pas les pinceaux
ca, c'est plus compliqué qu'il n'y parait car on retombe sur les fonction generiques fabriquant les requetes d'insertion, il faudrait donc réintroduire du specifique, au moins pour le cas mots/mots
3- l'association aurait donc un sens (X affecté à Y different de Y affecté à X).
on pourrait eventuellement prevoir 2 criteres pour pouvoir ou non tenir compte du sens, mais pour ce qui est des "boite d'affectation", on serait obligé d'en tenir compte (il me semble)
du coup, il faut doubler, au moins pour mots (encore une exception...) la presentation des mots : ce mots est affecté à X,Y,Z ET les mots X, Y, Z lui sont affectés.
Conclusion : rien d'impossible, mais c'est du taf.
le truc potentiellement le plus problematique, c'est ce changement de fonctionnement de l'affectation qui risque d'amener des incompatibilités avec les plugins integrant des surcharges (agenda, F&T, peut etre d'autres...)
aujourd'hui, en passant avant (en 1.9.2, en nommant le plugin "_mots_partout), on reste compatible.
Donc pour le faire proprement, il faudrait egalement penser à ces plugins qui ont mis en place leur propre interface d'affectation.
Ca montre qu'il faut sans doute gerer 2 interfaces d'affectation : la "boite" classique, et une liste à choix multiple (pour les documents, peut etre les articles syndiqués, ca se justifie sans doute aussi)
voila mes 2 sous, de quoi alimenter un peu la discussion...
@++
jusque la ca devait déjà etre dans le fichier todo