Salut,
j'ai fait une contrib basé sur le plugin mots_partout puisque surchargant les mêmes fichiers, qui permet de gérer les groupes de mots clefs arborescents.
les mots clefs ne le sont pas directement donc.
il y avait eu une discussion au niveau du développement de cette évolution fin juin ( le 19 entre autres).
Faut-il alors se baser sur mots techniques ou mots partout ?
Faudrait-il pas mieux intégrer une api pour les mots clefs afin de gérer ca de manière plus indépendante ?
Vous avez parler d'une API dans mots techniques, est-ce que vous pouvez m'en dire un tout petit peu plus ?
je ne trouve pas de docs pour mots techniques . C'est moi qui google mal ? ou c'est qu'il n'y en a pas encore ?
la pour le moment je me suis basé sur le plugin mots_partouts en surchargant ses fonctions... mais je comptais l'intégrer a mots_partouts.
Merci pour vos conseils 
Yoann NOGUES a écrit :
Salut,
j'ai fait une contrib basé sur le plugin mots_partout puisque surchargant les mêmes fichiers, qui permet de gérer les groupes de mots clefs arborescents.
les mots clefs ne le sont pas directement donc.
il y avait eu une discussion au niveau du développement de cette évolution fin juin ( le 19 entre autres).
Faut-il alors se baser sur mots techniques ou mots partout ?
Faudrait-il pas mieux intégrer une api pour les mots clefs afin de gérer ca de manière plus indépendante ?
Vous avez parler d'une API dans mots techniques, est-ce que vous pouvez m'en dire un tout petit peu plus ?
je ne trouve pas de docs pour mots techniques . C'est moi qui google mal ? ou c'est qu'il n'y en a pas encore ?
la pour le moment je me suis basé sur le plugin mots_partouts en surchargant ses fonctions... mais je comptais l'intégrer a mots_partouts.
Merci pour vos conseils 
mots_techniques est une proposition de modification du core. Pour plus de détails voir ici :
http://trac.rezo.net/trac/spip/ticket/913
et ici :
Pour l'éventuelle intégration de mots techniques dans le core, il vaut mieux relancer une discussion sur spip-dev.
Ensuite, mots_partout a vocation d'évoluer en tant que plugin central d'extension des fonctionnalités des mots-clés. Si les mots-clés techniques font leur entrée dans le core, il est évident que mots_partout évoluera pour rester compatible avec le core.
Joseph a écrit :
Yoann NOGUES a écrit :
Salut,
j'ai fait une contrib basé sur le plugin mots_partout puisque surchargant les mêmes fichiers, qui permet de gérer les groupes de mots clefs arborescents.
les mots clefs ne le sont pas directement donc.
il y avait eu une discussion au niveau du développement de cette évolution fin juin ( le 19 entre autres).
Faut-il alors se baser sur mots techniques ou mots partout ?
Faudrait-il pas mieux intégrer une api pour les mots clefs afin de gérer ca de manière plus indépendante ?
Vous avez parler d'une API dans mots techniques, est-ce que vous pouvez m'en dire un tout petit peu plus ?
je ne trouve pas de docs pour mots techniques . C'est moi qui google mal ? ou c'est qu'il n'y en a pas encore ?
la pour le moment je me suis basé sur le plugin mots_partouts en surchargant ses fonctions... mais je comptais l'intégrer a mots_partouts.
Merci pour vos conseils
mots_techniques est une proposition de modification du core. Pour plus de détails voir ici :
http://trac.rezo.net/trac/spip/ticket/913
et ici :
Connexion · GitLab
Pour l'éventuelle intégration de mots techniques dans le core, il vaut mieux relancer une discussion sur spip-dev.
Ensuite, mots_partout a vocation d'évoluer en tant que plugin central d'extension des fonctionnalités des mots-clés. Si les mots-clés techniques font leur entrée dans le core, il est évident que mots_partout évoluera pour rester compatible avec le core.
oui, c'est comme ca que j'avais compris la chose aussi.
et puis il ne faut pas oublier que mots_partout, à la base, c'est de Pierre (Mortimer) => interface permettant l'affectation de mots par lots et l'extension aux documents et auteurs.
Moi j'ai etendu ca à n'importe quel objet, au depart pour spipcarto, mais tout ce qui vient en plus sans casser ce perimetre de base est à priori bienvenu
Pour l'instant j'ai pas eu le besoin ni le temps d'integrer les mots clés techniques, mais ca me parait necessaire, donc de toutes facons, ils finiront au moins dans mots_partout pour pouvoir gerer les 2 besoins.
pour l'arborescence de groupe, ca me parait tres utile aussi, donc pourquoi pas l'integrer directement à mots_partout effectivement (optionnel ca serait mieux) ?
je fais deja des arborescences en affectant des mots à des groupes, mais c'est vrai que c'est un peu plus compliqué à gerer et à mettre en place.
En plus, l'avantage, c'est que les 2 approches ne sont pas incompatibles.
bref, n'hesitez pas à mettre vos petites affaires dans mots_partout.
@++
Yoann NOGUES a écrit :
Salut,
j'ai fait une contrib basé sur le plugin mots_partout puisque surchargant les mêmes fichiers, qui permet de gérer les groupes de mots clefs arborescents.
au fait, j'ai pas compris "il faudrait avoir ceci avec un gestion intervallaire des arbres et pas une gestion simple "
tu peux expliquer ?
Joseph a écrit :
mots_techniques est une proposition de modification du core. Pour plus de détails voir ici :
http://trac.rezo.net/trac/spip/ticket/913
et ici :
Connexion · GitLab
Pour l'éventuelle intégration de mots techniques dans le core, il vaut mieux relancer une discussion sur spip-dev.
Ensuite, mots_partout a vocation d'évoluer en tant que plugin central d'extension des fonctionnalités des mots-clés. Si les mots-clés techniques font leur entrée dans le core, il est évident que mots_partout évoluera pour rester compatible avec le core.
______
Donc intégrer ce genre de fonctionnalités au plugin mots_partout est la meilleure des choses a faire ?
Pour l'heure j'ai un truc abouti fonctionnellement( en surchargeant les fichiers du plugin mots_partout ) , il me reste a modifier peut-être l'interface "mots_tous" qui lorsque l'on a beaucoup de mots clefs devient illisisble...
Stephane a écrit :
Yoann NOGUES a écrit :
Salut,
j'ai fait une contrib basé sur le plugin mots_partout puisque surchargant les mêmes fichiers, qui permet de gérer les groupes de mots clefs arborescents.
au fait, j'ai pas compris "il faudrait avoir ceci avec un gestion intervallaire des arbres et pas une gestion simple "
tu peux expliquer ?
2 approches existent pour la hiérarchie dans une table :
1- l'approche simple : ( id_parent dans la table spip_groupes_mots , et cet id_parent prend comme valeur l'identifiant id_groupe du pére )
2- l'approche intervallaire : largement mieux en terme de perf, surtout si l'arborescence est complexe : plus d'infos SQLPro - Représentation intervallaire des arborescences
il en était question dans une discussion sur cette liste le 19 juin, j'ai donc repris ces discussions comme base ( mais étant donné ce que ca demande en dév en plus par rapport a mon besoin primaire je n'ai pris cette info comme importante dans mon dév )
Yoann NOGUES a écrit :
Joseph a écrit :
mots_techniques est une proposition de modification du core. Pour plus de détails voir ici :
http://trac.rezo.net/trac/spip/ticket/913
et ici :
Connexion · GitLab
Pour l'éventuelle intégration de mots techniques dans le core, il vaut mieux relancer une discussion sur spip-dev.
Ensuite, mots_partout a vocation d'évoluer en tant que plugin central d'extension des fonctionnalités des mots-clés. Si les mots-clés techniques font leur entrée dans le core, il est évident que mots_partout évoluera pour rester compatible avec le core.
______
Donc intégrer ce genre de fonctionnalités au plugin mots_partout est la meilleure des choses a faire ?
moi je suis pour en tous cas...
tu peux me l'envoyer que je regarde ca ?
Pour l'heure j'ai un truc abouti fonctionnellement( en surchargeant les fichiers du plugin mots_partout ) , il me reste a modifier peut-être l'interface "mots_tous" qui lorsque l'on a beaucoup de mots clefs devient illisisble...
il faudrait sans doute ajouter ca à la config et rendre l'affichage optionnel sur le groupe de mot
Yoann NOGUES a écrit
2 approches existent pour la hiérarchie dans une table :
1- l'approche simple : ( id_parent dans la table spip_groupes_mots , et cet id_parent prend comme valeur l'identifiant id_groupe du pére )
2- l'approche intervallaire : largement mieux en terme de perf, surtout si l'arborescence est complexe : plus d'infos SQLPro - Représentation intervallaire des arborescences
il en était question dans une discussion sur cette liste le 19 juin, j'ai donc repris ces discussions comme base ( mais étant donné ce que ca demande en dév en plus par rapport a mon besoin primaire je n'ai pris cette info comme importante dans mon dév )
oui et puis c'est un peu galere à mettre en place car il faut revoir la numerotation à chaque modif...
Si le seul avantage, c'est les perfs, avec le cache de spip, c'est pas tres utile, et puis il faudrait d'abord mettre ca en place sur les rubriques.
l'approche simple a en plus l'avantage de pouvoir profiter du critere branche.
Stephane a écrit :
Yoann NOGUES a écrit
2 approches existent pour la hiérarchie dans une table :
1- l'approche simple : ( id_parent dans la table spip_groupes_mots , et cet id_parent prend comme valeur l'identifiant id_groupe du pére )
2- l'approche intervallaire : largement mieux en terme de perf, surtout si l'arborescence est complexe : plus d'infos SQLPro - Représentation intervallaire des arborescences
il en était question dans une discussion sur cette liste le 19 juin, j'ai donc repris ces discussions comme base ( mais étant donné ce que ca demande en dév en plus par rapport a mon besoin primaire je n'ai pris cette info comme importante dans mon dév )
oui et puis c'est un peu galere à mettre en place car il faut revoir la numerotation à chaque modif...
Si le seul avantage, c'est les perfs, avec le cache de spip, c'est pas tres utile, et puis il faudrait d'abord mettre ca en place sur les rubriques.
l'approche simple a en plus l'avantage de pouvoir profiter du critere branche.
j'ai encore quelques modifs a faire pour le "finaliser" ou rendre public car la c'est du gros bidouillage .... je mets ca au propre demain matin
++
j'ai encore quelques modifs a faire pour le "finaliser" ou rendre public car la c'est du gros bidouillage .... je mets ca au propre demain matin
++
Salut,
le demain matin s'est transformé en quelques jours aprés, mais ca y est je pense avoir un truc de potable.
je suis parti de la modif du plugin mots_partout.
Cela permet :
- de définir un sous groupe a chaque de mots clefs, j'ai pris le principe d'une arborescence classique et pas en arbre
- de voir apparaitre sous forme de select indenté l'arborescence de chaque groupe de mots (en partant de la racine on va dire)
- les groupes de mots clefs sont considérés comme "actifs" dés lors qu'ils ont un mot clef a l'intérieur( principe actuel ) ou lors d'un sous groupe associé a ce groupe avec l'autorisation bien sur pour l'utilisateur connecté (je n'ai pas gardé le principe des mots clefs dans les sous-groupes car ca peut vite devenir un gouffre sql et que perso je n'en ai pas l'utilité )
- j'ai gardé l'interface des groupes de mots clefs ( mais ca devient vite un calvaire lorsque l'on a beaucoup de groupe) donc ca serait éventuellement a modifier
- chaque groupe de mots clefs ( quelque soit son niveau dans cette arborescence ) conserve ses propriétés d'attribution a tel ou tel objet, ainsi que les niveaux d'accés par les rédacteurs ou administrateurs.
- Dans l'interface publique, une simple boucle récursive grace au critére {parent} permet d'obtenir l'arborescence
Vous voulez que je commit ou je vous fait un patch(diff)? ou que j'en fasse une contrib juste ?
le commit dans _plugins_/_test_/mots_partout/1.9.2 ?
Merci et a bientot(bon app a tous)
Salut,
Yoann NOGUES a écrit :
Vous voulez que je commit ou je vous fait un patch(diff)? ou que j'en fasse une contrib juste ?
le commit dans _plugins_/_test_/mots_partout/1.9.2 ?
oui, tu peux commiter la si tu veux, comme ca on aura les diffs en meme temps...
Par contre, il faudrait maintenir la version actuelle pour generer le zip (au moins le temps de verifier que tout marche bien et eventuellement affiner un peu les interface et la configuration)
sans doute (à verifier) dans archiveliste.txt :
108c108,109
< _plugins_/_test_/mots_partout/1.9.2/;mots-partout_1_9_2;mots_partout_1_9_2
---
> _plugins_/_test_/mots_partout/1.9.2/;mots-partout_1_9_2:12472;mots_partout_1_9_2
> _plugins_/_test_/mots_partout/1.9.2/;mots-partout_1_9_2;mots_partout_arbo_1_9_2
comme ca les 2 versions seront disponibles en zip.
@++
Merci et a bientot(bon app a tous)
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Stephane a écrit :
le commit dans _plugins_/_test_/mots_partout/1.9.2 ?
oui, tu peux commiter la si tu veux, comme ca on aura les diffs en meme temps...
ce sera fait demain au petit matin
Yoann NOGUES a écrit :
Stephane a écrit :
le commit dans _plugins_/_test_/mots_partout/1.9.2 ?
Il manque dans mon code l'installation de l'id_parent dans la table spip_groupe_mots, une idée où rajouter ca ?
oui, dans exec/config_mots_partout
c'est pas tres clean (il faudrait une action pour respecter vraiment la logique spip...) mais c'est efficace.
il faudrait en fait mettre un meta pour savoir si c'est actif ou non et faire le alter table à la premiere activation (ou si le champ n'existe pas... ou alors on fait le alter à l'activation sans se poser de question).
je n'ai pas fait la désinstallation complete encore, mais il faudra y penser aussi.
j'ai bien penser le mettre dans la config de mots partout, mais ca impliquerai d'activer ca
dans une prochaine version de m'attelerai a rendre cela optionnel.
commite deja ce que tu as, pour l'instant j'ai pas vu ton code, donc j'ai pas grand chose à en dire...
++
Yoann NOGUES a écrit :
Stephane a écrit :
le commit dans _plugins_/_test_/mots_partout/1.9.2 ?
c'est commit reste a tester...
attention je n'ai pas encore rajouter dans l'install / config l'ajout du champ id_parent dans la table spip_groupes_mots ( ca va rapidement poser des problémes a mon avis)
la j'ai pas trop le temps, par contre si ya des bugs faites m'en part
a +