J'aimerai relancer les discussions sur les mots clés techniques.
Actuellement, le plugin est fonctionnel (en svn)(dans /_plugins_/dev/).
Pour résumer, ce plugin propose lors de la création d'un groupe de mots clés, de définir celui-ci comme 'technique'.
1)
Les mots clés appartenant à un groupe technique ne sont alors pas selectionnés par une boucle MOTS. Idem pour une boucle GROUPES_MOTS avec les groupes.
- Pour afficher tous les mots ou groupes, il faut utiliser {tout}
- Pour afficher les mots ou groupes technique {technique=oui}
2)
Le plugin crée aussi un nouveau champ 'affiche_formulaire' (trouver un nom plus explicite ?) par défaut à 'oui' et non modifiable par l'utilisateur.
Un groupe ayant ce champ sur 'oui' affiche le formulaire d'ajout de mot clé aux rubriques, articles... comme actuellement dans SPIP.
3)
Soit un plugin X souhaitant utiliser des mots clés techniques, il peut à son installation créer les groupes de mots
- en remplissant le champ 'technique' à 'oui' ou une autre valeur (attention, une autre valeur ne permet pas aux administrateurs de créer des mots clés depuis l'interface d'édition des mots de SPIP dans ce groupe)
- en remplissant le champ 'affiche_formulaire' à 'oui' ou 'non'
----
Est-ce que vous voyez des choses à redire là dessus, des choses à changer ?
Ca me paraît très bien, sauf "affiche_formulaire", qui serait mieux
servi, il me semble, par un appel à un autoriser() spécifique. Car
rapidement on va vouloir, pour certains groupes de mots, les autoriser
[ ] à tous [ ] aux auteurs de l'article [ ] aux admins [ ] à
personne etc. Le oui/non ne sera alors ni suffisant ni générique
Ca me paraît très bien, sauf "affiche_formulaire", qui serait mieux
servi, il me semble, par un appel à un autoriser() spécifique. Car
rapidement on va vouloir, pour certains groupes de mots, les autoriser
à tous aux auteurs de l'article aux admins à
personne etc. Le oui/non ne sera alors ni suffisant ni générique
-- Fil
Oui, c'est intéressant ce que tu dis.
de mémoire, on a la possibilité de créer :
- autoriser_action()
- autoriser_objet_action()
action peut être 'voirMots' ou 'editerMots' ou 'formulaireMots' ou je ne sais quoi de plus clair....
Mais comment faire une action en fonction du champ 'technique' du groupe de mot clé ? ça veut dire qu'il faut le passer dans le paramètre $opt de autoriser() ? et ensuite essayer d'appeler une éventuelle fonction
- autoriser_objet_action_param() ?
J'aimerai relancer les discussions sur les mots clés techniques.
Actuellement, le plugin est fonctionnel (en svn)(dans /_plugins_/dev/).
Pour résumer, ce plugin propose lors de la création d'un groupe de mots clés, de définir celui-ci comme 'technique'.
1)
Les mots clés appartenant à un groupe technique ne sont alors pas selectionnés par une boucle MOTS. Idem pour une boucle GROUPES_MOTS avec les groupes.
- Pour afficher tous les mots ou groupes, il faut utiliser {tout}
- Pour afficher les mots ou groupes technique {technique=oui}
2)
Le plugin crée aussi un nouveau champ 'affiche_formulaire' (trouver un nom plus explicite ?) par défaut à 'oui' et non modifiable par l'utilisateur.
Un groupe ayant ce champ sur 'oui' affiche le formulaire d'ajout de mot clé aux rubriques, articles... comme actuellement dans SPIP.
3)
Soit un plugin X souhaitant utiliser des mots clés techniques, il peut à son installation créer les groupes de mots
- en remplissant le champ 'technique' à 'oui' ou une autre valeur (attention, une autre valeur ne permet pas aux administrateurs de créer des mots clés depuis l'interface d'édition des mots de SPIP dans ce groupe)
- en remplissant le champ 'affiche_formulaire' à 'oui' ou 'non'
----
Est-ce que vous voyez des choses à redire là dessus, des choses à changer ?
2)
Le plugin crée aussi un nouveau champ 'affiche_formulaire' (trouver un nom plus explicite ?) par défaut à 'oui' et non modifiable par l'utilisateur.
Un groupe ayant ce champ sur 'oui' affiche le formulaire d'ajout de mot clé aux rubriques, articles... comme actuellement dans SPIP.
Autrement dit, est-ce que ça doit afficher (comportement actuel de SPIP) ou non la liste déroulante de sélection des mots clefs du groupe dans les articles, rubriques...
2)
Le plugin crée aussi un nouveau champ 'affiche_formulaire' (trouver un nom plus explicite ?) par défaut à 'oui' et non modifiable par l'utilisateur.
Un groupe ayant ce champ sur 'oui' affiche le formulaire d'ajout de mot clé aux rubriques, articles... comme actuellement dans SPIP.
Bien, là, rien ne change par rapport à ce que fait actuellement SPIP :
il propose dans les pages articles d'ajouter les mots clés.
Ce champs doit permettre à des plugins de dire "ne propose pas d'ajouter les mots clés de mon groupe technique, il me sert à autre chose".
de mémoire, on a la possibilité de créer :
- autoriser_action()
- autoriser_objet_action()
action peut être 'voirMots' ou 'editerMots' ou 'formulaireMots' ou je ne sais quoi de plus clair....
autoriser_mot_voir plutot, non ?
Mais comment faire une action en fonction du champ 'technique' du groupe de mot clé ?
la logique voudrait que ca passe par action/editer_mot (pas de modif necessaire je pense) mais de memoire, en 1.9.2, les modifs passaient par instituer_mot ce qui n'est pas tres logique
pas sur que ca soit mieux en SVN...
ça veut dire qu'il faut le passer dans le paramètre $opt de autoriser() ? et ensuite essayer d'appeler une éventuelle fonction
- autoriser_objet_action_param() ?
normalement, si j'ai bien compris la mecanique, pas de trucs compliqués à faire :
action_editer_xxx_dist() de action/editer_xxx.php est appelée et fait appel à inc_editer_xxx() de inc/editer_xxx.php qui fait la sauvegarde via revision_xxx() ou ajouter_xxx()
Mais les mots clés ne sont pas le parfait exemple de mise en pratique....
action peut être 'voirMots' ou 'editerMots' ou 'formulaireMots' ou je ne
sais quoi de plus clair....
en effet peut-être qqchose comme
autoriser('modifier', 'lienmot', NULL NULL, array('type' => 'article',
'id' => id_article, 'id_groupe' => X))
-- Fil
alors autoriser_liermot() et autoriser_objet_liermot() semble pas mal oui; 'lier' à la place de lien, action = verbe non ?
Pour la suite, on envoie id_groupe. OK. Mais comment un plugin peut-il connaitre l'id du groupe voulu ?
Quelle fonction les plugins peuvent surcharger pour modifier ces éléments. Il me semble que autoriser_objet_liermot() n'est pas suffisant car trop de plugins vont l'utiliser et vont se marcher dessus.
Mettre 'autoriser_objet_liermot_titreDuGroupe() c'est rencontrer à coup sûr des problèmes avec les encodages du titre.
Ou alors autoriser_objet_liermot_valeurChampTechnique() qui a plus de chance d'être un identifiant sans accent (encore que!)...
Quelle fonction les plugins peuvent surcharger pour modifier ces
éléments. Il me semble que autoriser_objet_liermot() n'est pas
suffisant car trop de plugins vont l'utiliser et vont se marcher dessus.
Si c'est un pipeline bien fait (dans lequel chaque plugin peut
répondre OUI, NON ou "je passe")
J'ai encore des cours de pipeline à prendre moi ou je ne comprends pas...
Tu proposes de mettre un pipeline() à l'intérieur de la fonction autoriser('liermot') ?
Ou alors autoriser_objet_liermot_valeurChampTechnique() qui a plus de
chance d'être un identifiant sans accent (encore que!)...
>> Quelle fonction les plugins peuvent surcharger pour modifier ces
>> éléments. Il me semble que autoriser_objet_liermot() n'est pas
>> suffisant car trop de plugins vont l'utiliser et vont se marcher dessus.
>
> Si c'est un pipeline bien fait (dans lequel chaque plugin peut
> répondre OUI, NON ou "je passe")
>
J'ai encore des cours de pipeline à prendre moi ou je ne comprends pas...
Tu proposes de mettre un pipeline() à l'intérieur de la fonction
autoriser('liermot') ?
Oui, si on pense que plusieurs plugins peuvent intervenir il faut
qu'ils puissent s'inscrire pour avoir chacun une chance de traiter la
donnée : c'est à ça que sert un pipeline