Salut,
est-ce qu'il serait possible de mettre _plugins_/tablesorter sur git ?
J'aimerais
1) créer un plugin tablesorter_lib qui se contente de fournir la lib
2) modifier, en créant une branche, le plugin tablesorter actuel pour qu'il appel le plugin sus-dit et s'en serve
3) modifier formidable_tablesorter pour qu'il appelle tablesorter_lib
Le 19/11/2019 à 14:42, Maïeul a écrit :
Salut,
est-ce qu'il serait possible de mettre _plugins_/tablesorter sur git ?
J'aimerais
1) créer un plugin tablesorter_lib qui se contente de fournir la lib
2) modifier, en créant une branche, le plugin tablesorter actuel pour qu'il appel le plugin sus-dit et s'en serve
3) modifier formidable_tablesorter pour qu'il appelle tablesorter_lib----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
le mail est parti trop vite : Merci d'avance
Maïeul
Le 19/11/2019 à 14:42, Maïeul a écrit :
2) modifier, en créant une branche, le plugin tablesorter actuel pour qu'il appel le plugin sus-dit et s'en serve
Mais si le plugin Tablesorter s'appelle comme ça tout court, ça serait pas plus logique de faire en sorte qu'il fournisse la lib et lui ajoute de la config pour que le fait qu'il applique cette lib à ci ou ça soit optionnel ?
Parce que bon, son code, c'est vraiment juste la lib elle-même, et 10 pauvres lignes de plus qui l'appel pour l'activer. Alors sur-découper encore plus…
--
RastaPopoulos
Le 19/11/2019 à 14:49, RastaPopoulos a écrit :
Le 19/11/2019 à 14:42, Maïeul a écrit :
2) modifier, en créant une branche, le plugin tablesorter actuel pour qu'il appel le plugin sus-dit et s'en serve
Mais si le plugin Tablesorter s'appelle comme ça tout court, ça serait pas plus logique de faire en sorte qu'il fournisse la lib et lui ajoute de la config pour que le fait qu'il applique cette lib à ci ou ça soit optionnel ?
Parce que bon, son code, c'est vraiment juste la lib elle-même, et 10 pauvres lignes de plus qui l'appel pour l'activer. Alors sur-découper encore plus…
dans l'absolu je suis d'accord avec toi, mais quid de la config par défaut ? si on met non, on casse lors de la mise à jour, si on met "oui" il y a fort à parier qu'elle restera comme cela, toujours activée, même lorsque pas besoin.
Le 19/11/2019 à 15:13, Maïeul a écrit :
dans l'absolu je suis d'accord avec toi, mais quid de la config par défaut ? si on met non, on casse lors de la mise à jour, si on met "oui" il y a fort à parier qu'elle restera comme cela, toujours activée, même lorsque pas besoin.
S'il y avait déjà des choses enregistrées dans la base (donc une meta version base) on pourrait alors l'activer seulement pour ceux qui l'ont déjà activé, et le laisser désactiver par défaut pour les nouvelles installations.
Mais ce n'est pas le cas.
Si tu fais une nouvelle branche version majeure avec de la config, ça ne parait pas choquant que ça devienne tout désactivé par défaut, et qu'il faut aller le réactiver pour les anciens qui mettent à jour à cette nouvelle branche majeure.
On essaye de garder au maximum de la compatibilité ascendante, et parfois on ne peut pas, mais là juste aller cocher une ou deux cases dans un formulaire, c'est vraiment pas du gros cassage quoi ! C'est pas comme si ça cassait complètement le code et que les gens devaient tout refaire leurs squelettes, etc.
--
RastaPopoulos
Le 19/11/2019 à 15:55, RastaPopoulos a écrit :
Le 19/11/2019 à 15:13, Maïeul a écrit :
dans l'absolu je suis d'accord avec toi, mais quid de la config par défaut ? si on met non, on casse lors de la mise à jour, si on met "oui" il y a fort à parier qu'elle restera comme cela, toujours activée, même lorsque pas besoin.
S'il y avait déjà des choses enregistrées dans la base (donc une meta version base) on pourrait alors l'activer seulement pour ceux qui l'ont déjà activé, et le laisser désactiver par défaut pour les nouvelles installations.
Mais ce n'est pas le cas.
Si tu fais une nouvelle branche version majeure avec de la config, ça ne parait pas choquant que ça devienne tout désactivé par défaut, et qu'il faut aller le réactiver pour les anciens qui mettent à jour à cette nouvelle branche majeure.
mouais, le problème est que svp est pas capable de voir la différence entre version majeure et mineure, et donc de signaler ce genre de chose.
Un tierce avis serait bienvenue
Hop,
Le 19/11/2019 à 16:09, Maïeul a écrit :
Un tierce avis serait bienvenue
Un tierce avis comme celui que j'ai déjà donné ? ^^
https://www.mail-archive.com/spip-zone@rezo.net/msg49002.html
En fait le truc c'est que du plugin tablesorter existant, je veux la lib, mais QUE la lib. Je ne veux pas qu'il me l'installe automatiquement sur toutes les pages (comme c'est le cas actuellement) ni qu'il ajoute automatiquement un js pour l'activer sur certains tableaux.
Tu peux ajouter un autre define (en plus de celui que je proposais) au plugin initial afin que celui-ci ne fasse rien depuis les pipeline insert_head* et header_prive, ainsi il ne fera que founir la lib à ton nouveau plugin.
++
b_b
Le 19/11/2019 à 16:21, Bruno Bergot a écrit :
Hop,
Le 19/11/2019 à 16:09, Maïeul a écrit :
Un tierce avis serait bienvenue
Un tierce avis comme celui que j'ai déjà donné ? ^^
https://www.mail-archive.com/spip-zone@rezo.net/msg49002.html
oui j'avais vu, mais cela ne résoudrait pas le souci
En fait le truc c'est que du plugin tablesorter existant, je veux la lib, mais QUE la lib. Je ne veux pas qu'il me l'installe automatiquement sur toutes les pages (comme c'est le cas actuellement) ni qu'il ajoute automatiquement un js pour l'activer sur certains tableaux.
Tu peux ajouter un autre define (en plus de celui que je proposais) au plugin initial afin que celui-ci ne fasse rien depuis les pipeline insert_head* et header_prive, ainsi il ne fera que founir la lib à ton nouveau plugin.
oki, donc tu serais de l'avis Rasta, de mettre une conf, mais plutot sous forme de define plus qu'en base. Pourquoi pas, je sais jamais ce qui est le mieux 
Mais dans tous les cas on resterait sur : le plugin actuel fournirait la lib + si on lui demande explicitement intégrerai des fonctions directement.
++
b_b
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Re,
Le 19/11/2019 à 16:28, Maïeul a écrit :
Mais dans tous les cas on resterait sur : le plugin
actuel fournirait la lib + si on lui demande explicitement intégrerai des fonctions directement.
Non, je pense qu'il est plus sympa pour les users de laisser le plugin existant tel quel, donc :
si on lui demande explicitement de ne pas le faire, il n'insère rien
++
b_b
Le 19/11/2019 à 16:34, Bruno Bergot a écrit :
Non, je pense qu'il est plus sympa pour les users de laisser le plugin existant tel quel, donc :
si on lui demande explicitement de ne pas le faire, il n'insère rien
Moi je pense l'inverse.
Si on fait une nouvelle version majeure :
- le plugin ne fournit déjà quasiment que la lib, il n'y a presque pas de code en plus à part l'appel
- il est uniquement destiné à des dévs intégration, et il ne fait absolument rien tout seul, il demande de toute façon que les gens codent des choses précises dans leurs squelettes
- donc ça ne gène pas des masses que lors d'un saut de version majeure, on leur demande juste comme mini modif de penser à activer l'insertion de la lib
- cela permet par contre de faire en sorte que le plugin soit réellement générique et puisse être utilisé uniquement pour nécessiter la lib ; alors que sinon, c'est aux gens de penser à le désactiver pour ne pas se la trimbaler partout
--
RastaPopoulos
Hop,
Le 19/11/2019 à 19:48, RastaPopoulos a écrit :
Le 19/11/2019 à 16:34, Bruno Bergot a écrit :
Non, je pense qu'il est plus sympa pour les users de laisser le plugin existant tel quel, donc :
si on lui demande explicitement de ne pas le faire, il n'insère rien
Moi je pense l'inverse.
Moi je tente de penser en tant qu'utilisateur *actuel* du plugin (puisque je ne l'utilise pas ^^).
Si on fait une nouvelle version majeure :
- le plugin ne fournit déjà quasiment que la lib, il n'y a presque pas de code en plus à part l'appel
- il est uniquement destiné à des dévs intégration, et il ne fait absolument rien tout seul, il demande de toute façon que les gens codent des choses précises dans leurs squelettes
"devs intégrations" qui ont peut-être "livré" le plugin à des personnes qui ne sont que des admins de sites.
- donc ça ne gène pas des masses que lors d'un saut de version majeure, on leur demande juste comme mini modif de penser à activer l'insertion de la lib
Ça me chagrine toujours de voir un comportement changer comme ça, même si la "justification" du changement de version majeure indique que "ça va casser des trucs existants".
- cela permet par contre de faire en sorte que le plugin soit réellement générique et puisse être utilisé uniquement pour nécessiter la lib ; alors que sinon, c'est aux gens de penser à le désactiver pour ne pas se la trimbaler partout
À qui imposer ce changement ? Aux admins des sites ou aux gens qui souhaitent utiliser le plugin en tant que lib uniquement (des devs donc) ?
Mais bon, je ne pense pas que ça soit bien important quelle que soit la décision, le plugin est utilisé sur 54 sites d'après https://plugins.spip.net/tablesorter 
++
b_b
- cela permet par contre de faire en sorte que le plugin soit réellement générique et puisse être utilisé uniquement pour nécessiter la lib ; alors que sinon, c'est aux gens de penser à le désactiver pour ne pas se la trimbaler partout
À qui imposer ce changement ? Aux admins des sites ou aux gens qui souhaitent utiliser le plugin en tant que lib uniquement (des devs donc) ?
Mais bon, je ne pense pas que ça soit bien important quelle que soit la décision, le plugin est utilisé sur 54 sites d'après https://plugins.spip.net/tablesorter
bon finalement j'ai retenu l'option suivante
1) script insérés par défaut
2) une config plutot qu'une constante (histoire de ne pas avoir des _options chargés pour pas grand chose)
Je documente cela.