Rôles sur les liaisons et modifications de l'API d'édition de liens.
Bonjour,
Excellente réflexion...
Puis-je me permettre d'y ajouter l'une ou l'autre chose (qui pour certaines ne sont probablement pas dans les limites de votre projet):
Il serait utile que les tables de jointures (de liens) soient couvertes par Champs Extras. Spécifier un rôle, par exemple peut entraîner assez facilement le besoin de préciser une limite temporelle.
prenez l'exemple d'un objet "organismes" (une fiche décrivant un organismes) et d'un objet "personnes". Le rôle qu'une personne peut avoir relativement à un organisme est autrement plus complexe que celui d'un scripteur à un article (auteur, coauteur, rédacteur, correcteur, valideur, etc.)
Un même site peut avoir des besoins fort différents quant aux rôles entre deux mêmes objets.
Bon travail
RB
Coucou, si je puis me permettre de rajouter mon grain de sel en toute modestie : ne serait-il pas temps d'en finir avec les rôles fixes que connaît SPIP depuis ses débuts ?
S'il y a des déclarations de rôle dans des arrays on pourrait envisager de préparer une interface pour en rajouter et supprimer. Le cas échéant si c'est trop exiger pour le moment au moins stocker les rôles dans la bdd si ce n'est pas encore fait.
Qu'est-ce vous en pensez ?
klaus++
Coucou, si je puis me permettre de rajouter mon grain de sel en toute
modestie : ne serait-il pas temps d'en finir avec les rôles fixes que
connaît SPIP depuis ses débuts ?
Quels sont ces rôles dont tu parles ? Je ne parle pas du statut (redacteur, administrateur, webmestre) hein, mais du rôle de la liaison entre quelque chose et autre chose comme entre un auteur et un article, qui n'est pas forcément celui qui a «rédigé» l'article. C'est peut être simplement celui qui l'a frappé, ou relu, ou traduit, ou tout ça à la fois.
S'il y a des déclarations de rôle dans des arrays on pourrait envisager
de préparer une interface pour en rajouter et supprimer.
Oui, ça c'est une possibilité... future, mais ajouter via une BDD ne traduit pas le rôle...
Le cas échéant
si c'est trop exiger pour le moment au moins stocker les rôles dans la
bdd si ce n'est pas encore fait.Qu'est-ce vous en pensez ?
Il me semble que ça complique les choses non ?
MM.
Bon, alors j'ai confondu un peu les choses. Si je comprends bien maintenant tu parles de rajouter par exemple des "auteurs" qui ne sont pas vraiment des auteurs à des objets éditoriaux.
Mais est-ce que la question que je posais par rapport à une modif de SPIP permettant un workflow plus variable ne rejoint-elle pas ton intention ?
klaus++
Bonjour,
Rôles sur les liaisons et modifications de l'API d'édition de liens.
Travaillant sur la mise en place d'un moyen pour définir des rôles
sur les tables de liaisons (par exemple indiquer que tel auteur est le
rédacteur de l'article, et tel autre le traducteur ou correcteur), je
suis confronté à différents problèmes nécessitant d'adapter le
formulaire d'édition de liens et l'api d'édition qui va avec.J'aimerais bien un avis et d'autres éclairages, si vous avez le cœur de tout
lire
Je ne suis malheureusement pas du tout à la hauteur pour commenter les
choix techniques que tu proposes et qui m'ont l'air très bien !
Par contre, ce que je peux dire est que je crois ne pas être le seul à
avoir très envie d'avoir cette fonction dans SPIP (on a très récemment
parlé sur les listes SPIP des liens typés entre mots-clés, mais aussi
entre auteurs et entre articles).
Alors: *merci beaucoup *pour ces travaux d'approche qui ont l'air
forts intéressants... Je serais peut-être un peu moins dépassé quand
on commencera à parler IHM (et encore)...
Ce sont 2 choses différentes je pense.
Rasta faisait une synthèse de la sorte sur IRC hier je crois. Actuellement, SPIP mélange pour un auteur 2 choses : son statut et son groupe.
- le statut serait : l'auteur est il actif, en cours de validation, ou à la poubelle
- le groupe serait : dans quel groupe est il : visiteur, rédacteur, administrateur, webmestre (c'est cette partie que tu aimerais étendre),
un groupe donne certains droits, tout comme le statut donne des droits aussi.
Les rôles (sur les auteurs) sont encore autre chose. Je peux être rédacteur, mais avoir traduit l'article 3. Un rôle sur un auteur peut être différent du groupe d'appartenance.
- Ce type de liaison (le rôle entre un auteur et un article) pourrait aussi intervenir dans les autorisations. Par exemple dire qu'un traducteur peut modifier un article qu'il a traduit, mais pas l'article d'origine... Et qu'un "relecteur" sur l'article n'a aucun droit de modification. Cela pourrait être fait.
Mais ce n'est pas ce que je tente de décrire là, qui est une méthode pour pouvoir appliquer des rôles et les définir (sans préjuger des autorisations que ça pourrait impacter, qui est d'un autre ordre il me semble).
Cela dit, ça me fait penser qu'il pourrait y avoir un appel à une autorisation pour savoir si X peut lier A à B avec le rôle Z, autrement dit, à partir du moment où il peut y avoir des rôles définis entre A et B, que X peut lier A et B, peut il lier n'importe lequel des rôles proposés, ou seulement certains ? ...
Pour résumer sur les auteurs (ce qui est restrictif pour l'usage des types de liaisons, rôles) il devrait y avoir : statut, groupe (et rôle s'il est lié).
MM.
Rôles sur les liaisons et modifications de l'API d'édition de liens.
Travaillant sur la mise en place d'un moyen pour définir des rôles
sur les tables de liaisons (par exemple indiquer que tel auteur est le
rédacteur de l'article, et tel autre le traducteur ou correcteur), je
suis confronté à différents problèmes nécessitant d'adapter le
formulaire d'édition de liens et l'api d'édition qui va avec.J'aimerais bien un avis et d'autres éclairages, si vous avez le cœur de tout lire
Voilà tel que j'imagine les choses à ce jour.
0) Adapter la table de liens recevant le rôle
---------------------------------------------Ajouter la colonne rôle
Modifier sa clé primaire pour que l'unicité soit sur
(id_xx,objet,id_objet,role)
oui
1) Déclarer les rôles possibles
-------------------------------J'imagine une déclaration formelle pour les rôles et la colonne
utilisée dans la déclaration de l'objet éditorial sur laquelle
s'applique la liaison. Un exemple peut être :"roles_colonne" => "role",
"roles_titres" => array(
'redacteur' => 'info_statut_redacteur',
'traducteur' => 'roles_auteurs:traducteur',
'correcteur' => 'roles_auteurs:correcteur',
'relecteur' => 'roles_auteurs:relecteur',
),
"roles_objets" => array(
'articles' => array(
'choix' => array('redacteur', 'traducteur', 'correcteur', 'relecteur'),
'defaut' => 'redacteur'
)
#'*' => array()
)On indique la colonne dans la table de liaison (role par défaut),
la liste des rôles possibles pour l'ensemble de l'objet, avec leur
chaîne de traduction, et, pour chaque objet lié, la liste des
rôles que l'on peut appliquer. On peut utiliser '*' pour dire
«quelque soit l'objet». Enfin, parmi ces rôles, un est défini
comme la valeur par défaut pour ce type de liaison.
ça parait bien...
2) Modifier les squelettes appelés
----------------------------------...
3) Soumettre des actions de liaison avec rôle
---------------------------------------------...
4) Adapter le traitement du formulaire d'édition de lien
--------------------------------------------------------Ce formulaire doit pouvoir gérer les 2 types d'actions indiquées
et les faire SI la liaison permet effectivement des rôles.
Il appelle alors l'API d'édition de lien modifiée tel que suggéré si
dessous
Est-ce que ça ne serait pas plus simple de ne pas modifier les squelettes :
au lieu de permettre le choix du rôle dans la saisie, ce qui va fortement compliquer l'interface, proposer un formulaire de lien par role (ce qui dans la plupart des cas fonctionnera bien).
Du coup pas de modif de l'interface, juste un argument supplémentaire à passer à #FORMULAIRE_EDITER_LIENS :
<h3>Auteurs</h3>
#FORMULAIRE_EDITER_LIENS{auteurs,article,23,auteur}
<h3>Traducteurs</h3>
#FORMULAIRE_EDITER_LIENS{auteurs,article,23,traducteur}
La même interface permet de gérer ou non les rôles (et cela évite de tout forker et refaire pour gérer les roles).
Si aucun role passé, on utilise un role=''
5) Adapter et compléter d'API d'édition de lien
-----------------------------------------------Il y a à mon avis à séparer en 2 partie cette adaptation :
1) optionnelle : la modification des pipelines
2) à faire : gérer la création de rôles et la
suppression/modification de liens sous contraintes1) Pipelines
------------Les pipelines pre_edition_lien et post_edition_lien m'ont trompé
lorsque j'ai voulu les utiliser. Pour cause ils ne fonctionnent
pas comme "pre_edition" et "post_edition" et ne transmettent pas
dans $flux['data'] la liste des champs impactés par l'insertion.
Et il n'y a pas de pipeline sur la modification.Propositions :
- modifier $flux['data'] des pipelines pour qu'il devienne un
tableau des champs ajoutés ou modifiés (ou supprimés)
- ajouter le passage de ces pipelines dans l'étape de modification
d'un lien (fonction lien_set, appelé par objet_qualifier_lien)
Je pense que ces pipelines ne sont utilisés nulle part encore, je les avais ajouté par imitation de ce qui se fait sur les objets.
On peut donc les faire évoluer sans grand risque
2) Adapter
----------Actuellement, l'ajout, la modification ou la suppression se base
sur le postulat qu'il n'existe qu'un seul couple (id_xx, objet,
id_objet) et il faut donc pouvoir s'en passer dans certaines
situations.On peut séparer en 2 les adaptations à faire.
A) Il s'agit d'une part de pouvoir supprimer et modifier des
éléments lorsque le nombre de couples (id_xx, objet, id_objet)
est supérieur à 1, c'est à dire dès lors que l'on peut affecter
plusieurs rôles sur un même couple de liaison.B) Et d'autre part gérer l'insertion de plus d'un couple (id_xx,
objet, id_objet).A) Contraindre les suppressions et modifications
------------------------------------------------Proposition : modifier la fonction lien_where() pour accepter
un 5è paramètre $condition (ou tout autre nom) qui ajouterait
au where généré des conditions sur les valeurs transmises,
par exemple :$condition = array( 'role' => 'redacteur' )
limite pour la colonne 'role' à la valeur 'redacteur'.$condition = array( 'role' => array('redacteur', 'traducteur'))
limite à toutes ces valeurs...Il suffit ensuite que les différentes fonctions de recherche,
modification et suppression de lien puissent transmettre une
contrainte, en leur ajoutant un paramètre, tel que :objet_dissocier(array('auteur'=>3), array('article'=>11),
array('role'=>'redacteur'));
Dissocie la liaison auteur 3 | article 11 | redacteur
Il faut déterminer ce qu'on fait quand on demande a dissocier sans passer de role
Est-ce que ça veut dire 'supprimer le lien avec un role vide' ou 'supprimer tous les liens quel que soit le role' ?
Il faut voir ce que ça implique du point de vue du code existant qui appelle les fonctions sans spécifier de rôle...
objet_qualifier_liens(array('auteur'=>3), array('article'=>11),
array('truc'=>'muche'), array('role'=>'redacteur'));
Dissocie les liaisons (auteur 3 | article 11 | redacteur) et
(auteur 3 | article 11 | traducteur)
J'aurais tendance à ne pas créer de 4eme argument ici, et de passer role dans le 3eme (cf insertion ci-dessous)
...
B) Insertion de liens avec rôles
--------------------------------C'est le point qui semble le plus délicat (avec
objet_qualifier_liens possiblement).Le plus simple est d'ajouter également un paramètre :
objet_associer(array('auteur'=>3), array('article'=>11),
array('truc'=>'muche'), array('role'=>'redacteur'));On peut alors créer autant de liaisons que nécessaire, pour
peu que la clé primaire l'autorise, et si la liaison n'existe
pas déjà.Le cas embêtant est lorsque 'role' est aussi déclaré dans le
3e paramètre $set, et encore plus embêtant s'il est déclaré
dans ce paramètre $set, ET qu'il n'y a pas de 4e paramètre
passé.Quoi faire alors ?
Je dirais qu'il est inutile d'ajouter un 4eme argument dans objet_associer :
on y connait l'objet pivot, donc le champ role et on peut le récuperer dans l'argument set
cela évite tout risque d'ambiguité
...
b) objet_associer(array('auteur'=>3), array('article'=>11),
array('role'=>'traducteur'));
Cas ennuyant : on demande une affectation sur la colonne rôle
(et déclarée comme telle). Que fait-on :
- prendre toutes les liaisons et affecteur role=traducteur
dessus ?
- extraire 'role' et le passer dans $role automatiquement ?
du coup ça éviterait toute ambiguité et veut dire "si pas de liaison avec ce role, la créer"
Cédric
[...]
4) Adapter le traitement du formulaire d'édition de lien
--------------------------------------------------------Ce formulaire doit pouvoir gérer les 2 types d'actions indiquées
et les faire SI la liaison permet effectivement des rôles.
Il appelle alors l'API d'édition de lien modifiée tel que suggéré si
dessousEst-ce que ça ne serait pas plus simple de ne pas modifier les squelettes :
au lieu de permettre le choix du rôle dans la saisie, ce qui va fortement compliquer l'interface, proposer un formulaire de lien par role (ce qui dans la plupart des cas fonctionnera bien).Du coup pas de modif de l'interface, juste un argument supplémentaire à passer à #FORMULAIRE_EDITER_LIENS :
<h3>Auteurs</h3>
#FORMULAIRE_EDITER_LIENS{auteurs,article,23,auteur}<h3>Traducteurs</h3>
#FORMULAIRE_EDITER_LIENS{auteurs,article,23,traducteur}La même interface permet de gérer ou non les rôles (et cela évite de tout forker et refaire pour gérer les roles).
Si aucun role passé, on utilise un role=''
Effectivement c'est une solution qui pourrait être proposée. Au détail près que je dirais : si aucun rôle passé, on applique le rôle par défaut si précisé, et si l'objet gère les rôles.
Mais il y a tout de même un détail qui me chagrine, c'est que si un objet a 5 rôles différents avec un autre, proposer autant de formulaires et de liens alourdit pour le coup la page également, et peut dans certains cas rendre les saisies plus longues.
Genre si tu sais que X est à la fois producteur, acteur et scénariste d'un film Y (et non l'inverse), eh bien tout saisir en une fois me paraît plus agréable, par exemple avec un select multiple et la librairie chosen (http://harvesthq.github.com/chosen/) ce qui donne cet aperçu :
Il me semble que les 2 solutions ont chacune leurs avantages.
Propositions :
- modifier $flux['data'] des pipelines pour qu'il devienne un
tableau des champs ajoutés ou modifiés (ou supprimés)
- ajouter le passage de ces pipelines dans l'étape de modification
d'un lien (fonction lien_set, appelé par objet_qualifier_lien)Je pense que ces pipelines ne sont utilisés nulle part encore, je les avais ajouté par imitation de ce qui se fait sur les objets.
On peut donc les faire évoluer sans grand risque
Si, mais juste dans le plugin révisions, rien de dramatique.
[...]
A) Contraindre les suppressions et modifications
------------------------------------------------Proposition : modifier la fonction lien_where() pour accepter
un 5è paramètre $condition (ou tout autre nom) qui ajouterait
au where généré des conditions sur les valeurs transmises,
par exemple :
[...]
objet_dissocier(array('auteur'=>3), array('article'=>11),
array('role'=>'redacteur'));
Dissocie la liaison auteur 3 | article 11 | redacteurIl faut déterminer ce qu'on fait quand on demande a dissocier sans passer de role
Est-ce que ça veut dire 'supprimer le lien avec un role vide' ou 'supprimer tous les liens quel que soit le role' ?
Il faut voir ce que ça implique du point de vue du code existant qui appelle les fonctions sans spécifier de rôle...
Ah oui, je vois ce que tu veux dire. Des appels à objet_dissocier existants risquent de dissocier des choses qu'on ne voudrait pas si on les laisse tel-quels alors que la liaison se met à gérer des rôles.
Dans ma tête, je me disais que si on ne passe pas de contrainte, on supprime tous les couples (quelque soit le rôle donc). Mais effectivement, ça me questionne d'un coup 
objet_qualifier_liens(array('auteur'=>3), array('article'=>11),
array('truc'=>'muche'), array('role'=>'redacteur'));
Dissocie les liaisons (auteur 3 | article 11 | redacteur) et
(auteur 3 | article 11 | traducteur)J'aurais tendance à ne pas créer de 4eme argument ici, et de passer role dans le 3eme (cf insertion ci-dessous)
Oui, le seul ennui visible serait "Comment changer la valeur d'un rôle ?" Cela l'empêcherait. C'est cependant peut être pas si gênant que ça.
B) Insertion de liens avec rôles
--------------------------------
[...]
Je dirais qu'il est inutile d'ajouter un 4eme argument dans objet_associer :
on y connait l'objet pivot, donc le champ role et on peut le récuperer dans l'argument set
cela évite tout risque d'ambiguité
...
b) objet_associer(array('auteur'=>3), array('article'=>11),
array('role'=>'traducteur'));
Cas ennuyant : on demande une affectation sur la colonne rôle
(et déclarée comme telle). Que fait-on :
- prendre toutes les liaisons et affecteur role=traducteur
dessus ?
- extraire 'role' et le passer dans $role automatiquement ?du coup ça éviterait toute ambiguité et veut dire "si pas de liaison avec ce role, la créer"
Ouip, c'est ptet le plus simple logique effectivement pour ceux là.
MM.
Rôles sur les liaisons et modifications de l'API d'édition de liens.
Premier point : le mot "rôle" est quasiment spécifique aux auteurs (un rôle c'est souvent pour un humain). Ce mot ne me parait pas du tout générique pour l'ensemble des tables de liaison, et donc ne convient pas trop pour nommer l'API.
Rien n'empêche par contre d'utiliser le mot "role" pour les auteurs dans la déclaration explicite de la colonne :
'autremot_colonne' => 'role'
On parlerait plutôt de "typer" les liens. Le problème étant qu'un vieux nommage d'antan est d'utiliser "type" dans les mots-clés (au lieu de dire "groupe"). Et du coup pour ce vieux nommage mal fait (si si !) et bien ça gêne maintenant pour utiliser le mot "type" pour un besoin qui là le vaudrait bien... un peu couillon.
Donc du coup à part "type", je sais pas trop.
0) Adapter la table de liens recevant le rôle
---------------------------------------------
(id_xx,objet,id_objet,role)
Oui, c'est le plus simple ensuite pour les requêtes.
1) Déclarer les rôles possibles
-------------------------------
On indique la colonne dans la table de liaison (role par défaut),
la liste des rôles possibles pour l'ensemble de l'objet, avec leur
chaîne de traduction, et, pour chaque objet lié, la liste des
rôles que l'on peut appliquer. On peut utiliser '*' pour dire
«quelque soit l'objet». Enfin, parmi ces rôles, un est défini
comme la valeur par défaut pour ce type de liaison.
C'est très bien pour un développeur, mais au moins pour les liaisons d'auteurs, je me demande quand même ce que ça ferait pour les webmasters quand ils vont vouloir : un plugin qui ajoute un rôle PLUS un plugin qui ajoute un nouvel objet éditorial (et qui ne peut PAS connaitre les rôles disponibles).
Par exemple :
- un plugin *générique* ajoute un rôle "relecteur" avec des autorisations en conséquence (autoriser_relire_dist par exemple, générique quelque soit l'objet)
- un plugin ajoute un objet "produit"
Comment bénéficier de la nouvelle fonctionnalité de relecture (en supposant qu'elle est codée générique évidemment) ?
Tu me diras : et bien il faut que ce rôle soit pour tous les objets s'il est générique : '*' => array(..., 'relecteur', ...).
Sauf que cette histoire d'étoile, si on a 10 objets éditoriaux (article, brève, mot, gis, produit, organisation, etc) et bien on ne veut pas forcément de ces rôles sur TOUS les objets qu'on utilise sur le site.
Le problème, nous l'avions vu sur IRC, c'est que si on propose ça comme configuration, ça fait un tableau à double entrée, un peu chiant à configurer : pour chaque rôle, chaque objet (ou inversement).
N'empêche...
2) Modifier les squelettes appelés
----------------------------------
Ces squelettes doivent afficher une colonne rôle pour la vue, et
pour l'édition.
Je trouve ça plus logique qu'un formulaire par rôle.
Certes le solution de Cédric est plus simple techniquement, MAIS à mon avis ça sera intenable si on a ne serait-ce que 5 rôles (ça va vite) : 5 listes de personnes à la suite... avec souvent qu'une personne dedans... bof bof l'interface utilisateur quoi !
D'autant plus, tu l'as fait remarqué, qu'une même personne peut avoir plusieurs rôles à la fois pour un même objet. Je trouve donc ton idée de départ beaucoup mieux pour les utilisateurs.
Il vaut mieux passer un peu plus de temps à rendre encore plus générique l'API de liens, et encore plus personnalisable les squelettes de liste et les formulaires, si c'est pour que les utilisateurs aient une interface plus compréhensible à la fin.
3) Soumettre des actions de liaison avec rôle
---------------------------------------------
Et si on ne met pas le dernier alors que cette liaison a un typage, alors ça applique le type par défaut trouvé dans la description.
5) Adapter et compléter d'API d'édition de lien
-----------------------------------------------
A) Contraindre les suppressions et modifications
------------------------------
Cédric a écrit :
Il faut déterminer ce qu'on fait quand on demande a dissocier sans passer de role
Est-ce que ça veut dire 'supprimer le lien avec un role vide' ou 'supprimer tous les liens quel que soit le role' ?
Il faut voir ce que ça implique du point de vue du code existant qui appelle les fonctions sans spécifier de rôle...
Pour compatibilité, je propose que si rien n'est indiqué, l'action s'applique sur le type par défaut trouvé dans la description (par exemple "auteur" pour les liaisons d'auteurs).
Si un plugin ajoute un typage sur une table de liaison qui n'en avait pas, à priori il faut applique le type par défaut sur les liens existants au même de ce changement.
Seule la condition 'role' => '*' s'appliquera sur TOUS les rôles d'un même auteur.
B) Insertion de liens avec rôles
--------------------------------
Je pense aussi qu'il faut définir le type de liaison dans le même tableau que les qualifications. Après tout, le type d'une liaison c'est une des qualifications donc c'est logique.
Rôles sur les liaisons et modifications de l'API d'édition de liens.
Premier point : le mot "rôle" est quasiment spécifique aux auteurs (un
rôle c'est souvent pour un humain). Ce mot ne me parait pas du tout
générique pour l'ensemble des tables de liaison, et donc ne convient pas
trop pour nommer l'API.
Oui, encore que. Au vu de rôle — Wiktionnaire, le dictionnaire libre le point 9 indique que rôle n'est pas exclusif à une personne. Et peut être synonyme de «fonction, emploi».
Type type — Wiktionnaire, le dictionnaire libre également a d'autres signification, par exemple dans ce qui était proposé dans les objets typés : c'est l'objet lui-même qui reçoit un champ type (et non une liaison) indiquant son type et altérant du même coup les champs de saisie visibles. L'idée était de se baser sur la table articles pour faire des déclinaisons d'objets (comme le fait Diogène je crois de kent1 ou b_b), basés sur une seule table.
Je ne suis pas spécialement contre non plus, mais il me semble que dire «joue le rôle de» fonctionne quelque soit l'objet, tout comme on peut dire «est de type ».
- L'auteur 3 joue le rôle de «rédacteur» sur l'article 11
- L'auteur 3 est de type «rédacteur» sur l'article 11
- L'adresse 12 joue le rôle de «domicile» sur l'auteur 11
- L'adresse 12 est de type «domicile» sur l'auteur 11
- Le document 7 joue le rôle de «logo» sur la rubrique 2
- Le document 7 joue est de type «logo» sur la rubrique 2
[...]
0) Adapter la table de liens recevant le rôle
---------------------------------------------
(id_xx,objet,id_objet,role)Oui, c'est le plus simple ensuite pour les requêtes.
1) Déclarer les rôles possibles
-------------------------------
On indique la colonne dans la table de liaison (role par défaut),
la liste des rôles possibles pour l'ensemble de l'objet, avec leur
chaîne de traduction, et, pour chaque objet lié, la liste des
rôles que l'on peut appliquer. On peut utiliser '*' pour dire
«quelque soit l'objet». Enfin, parmi ces rôles, un est défini
comme la valeur par défaut pour ce type de liaison.C'est très bien pour un développeur, mais au moins pour les liaisons
d'auteurs, je me demande quand même ce que ça ferait pour les webmasters
quand ils vont vouloir : un plugin qui ajoute un rôle PLUS un plugin qui
ajoute un nouvel objet éditorial (et qui ne peut PAS connaitre les rôles
disponibles).
[...]
Je pense que dans ce cas précis (qui n'existe pas encore), la solution serait de simplement déclarer le titre du nouveau rôle.
Libre ensuite à ceux qui le désire, via pipeline d'indiquer que tel objet peut avoir ce nouveau rôle. Et il ne sera pas compliqué de réaliser une configuration graphique de tout ça, à partir de la liste des titres de rôles déclarés, et des objets éditoriaux déclarés.
Encore faut il que ces objets aient des squelette de liaisons réalisés, et éventuellement, suivant le choix fait, des squelettes de liaisons pour les rôles également.
2) Modifier les squelettes appelés
----------------------------------
Ces squelettes doivent afficher une colonne rôle pour la vue, et
pour l'édition.Je trouve ça plus logique qu'un formulaire par rôle.
Il me semble que les 2 se valent en fait.
Là où la proposition de Cédric est plus indiquée, c'est lorsque tu sais précisément ce que tu veux afficher dans le privé sur les objets (tu maîtrises les types liens du sites et tu sais que là tu n'as que ça et ça en types de liens).
À partir du moment où on dit que les rôles et leurs nombre sont à géométrie variable, il me semble que la solution d'avoir la colonne rôle est plus indiquée du coup.
[...]
3) Soumettre des actions de liaison avec rôle
---------------------------------------------Et si on ne met pas le dernier alors que cette liaison a un typage,
alors ça applique le type par défaut trouvé dans la description.5) Adapter et compléter d'API d'édition de lien
-----------------------------------------------
A) Contraindre les suppressions et modifications
------------------------------Cédric a écrit :
Il faut déterminer ce qu'on fait quand on demande a dissocier sans
passer de role
Est-ce que ça veut dire 'supprimer le lien avec un role vide' ou
'supprimer tous les liens quel que soit le role' ?
Il faut voir ce que ça implique du point de vue du code existant qui
appelle les fonctions sans spécifier de rôle...Pour compatibilité, je propose que si rien n'est indiqué, l'action
s'applique sur le type par défaut trouvé dans la description (par
exemple "auteur" pour les liaisons d'auteurs).Si un plugin ajoute un typage sur une table de liaison qui n'en avait
pas, à priori il faut applique le type par défaut sur les liens
existants au même de ce changement.Seule la condition 'role' => '*' s'appliquera sur TOUS les rôles d'un
même auteur.
Oui, on peut faire comme ça. Donc, si on veut supprimer tous les rôles, il faut forcément indiquer 'role' => '*' dans la contrainte, sinon ça prend le 'role' => $desc[qqc]['defaut']
B) Insertion de liens avec rôles
--------------------------------Je pense aussi qu'il faut définir le type de liaison dans le même
tableau que les qualifications. Après tout, le type d'une liaison c'est
une des qualifications donc c'est logique.
Bon, ça semble se préciser alors tout ça.
MM.
Bonjour,
je dis peut-être une bêtise ... mais en utilisant une autre approche: la possibilité de mettre des mots-clés sur une liaison (un triplet id_machin, objet, id_objet)?...
Ce qui permet la plus grande latitude à chacun, et en fonction des objets éditoriaux liés, de régler en finesse les rôles ou spécifications du lien avec toute la puissance de réglage des mots clés.
Bon travail
RB
En effet ça élargirait les possibilités à :
- des libellés entièrement définis par l'utilisateur
- plusieurs rôles d'un même groupe
- des rôles de plusieurs groupes (équivalents de plusieurs colonnes)
JL
Non.
Ce n'est pas une bêtise que de proposer cela.
Cependant. Si un jour il devait y avoir triplé, je pense que c'est un triplé avec une table spip_roles, et donc avec un id_role mais non pas avec des mots. Des mots clés doivent rester ce qu'ils sont : ce n'est pas un moyen de sélectionner des squelettes, ce n'est pas un moyen d'attribuer des autorisations ou des rôles non plus. Certes c'est pratique (interface, boucles) mais ce n'est pas sémantique. Et une information doit rester au maximum sémantique, sinon on perd son intérêt.
Pour résumer : des mots clés sur des objets OK, des mots clés sur des liaisons d'objet, pas OK, du moins, ce n'est pas le rôle des modifications que l'on souhaite.
MM.
Je vais tenter de faire une synthèse des quelques discussions qui ont eu lieu.
1) Le nom «role»
+1 avec marcimat
J'ajoute que plutôt que d'appeler ça un groupe ou un role, on pourrait appeler ça une qualité ou une qualification de la liaison :
"ceci est associé à cela en qualité de"
z'en pensez quoi ?
+1 avec marcimat
Salut James,
je ne pense pas non plus que les motcles soient la bonne manière d'implémenter cette fonctionnalité
mais la mise en parrallele éclaire bien les variations possibles dans l'usage des rôles.
J'ajoute que plutôt que d'appeler ça un groupe ou un role, on pourrait appeler ça une qualité ou une qualification de la liaison :
"ceci est associé à cela en qualité de"
z'en pensez quoi ?
C'est une bonne notion oui. J'avais pour ma part mentionné 'qualificatif'.
Mais je préfère quand même le terme 'role', qui est simple et court,
et qui s'applique parfaitement, aussi bien pour des "auteurs"
que pour d'autre éléments (non humains) qui remplissent une fonction.
JLuc
On m’a glissé “nature” qui est pas mal non plus 
Y a aussi "Relation"
MM.