[SPIP Zone] [Spip-zone-commit] r28844 - in /_plugins_/_stable_/citations_bien_balisees: ./ COPYING.txt citations_bb_pipelines.php css/ images/ plugin.xml

Samy_RABIH · Mai 27, 2009, 4:49

1 et 3 : ça n'entre pas en ligne de compte pour l'utilisateur final
2 : tu n'as pas tort mais un plugin n'est il pas un peu lourd pour ce genre d'améliorations?
-- msg original --
Sujet: Re: [Spip-zone-commit] r28844 - in /_plugins_/_stable_/citations_bien_balisees: ./ COPYING.txt citations_bb_pipelines.php css/ images/ plugin.xml
De: MARNE Bertrand <bmarne@gmail.com>
Date: 27.05.2009 18:39

2009/5/27 Samy Rabih <samy.rabih@free.fr>:

Question naive : on aurait pas pu en faire une lame du couteau suisse au
lieu de faire un plugin entier pour ça ?

1- je sais encore moins faire une lame du couteau suisse qu'un plugin
2- ça peut aussi intéresser des gens qui n'ont pas le cs ?
3- ça me fait progresser en SPIP/PHP...

sans parler du troll CS/plugins indépendants...

--
Bertrand Marne
_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

Bertrand_Marne · Mai 27, 2009, 5:11

Le 27 mai 2009 18:49, <samy.rabih@free.fr> a écrit :

2 : tu n'as pas tort mais un plugin n'est il pas un peu lourd pour ce genre d'améliorations?

je ne sais pas du tout... ce n'est effectivement qu'un preg_replace
dans un pipeline... Mais comment l'utilisateur normal fait ça ?

--
Bertrand Marne

Pat2 · Mai 27, 2009, 11:01

Bonjour à tous,

Ceci un excellent sujet de discussion : la différence entre <quote> et <q>...

Voici le code de cette lame du Couteau à placer dans config_outils.php,
en l'absence du fichier 'css/citations_bb.css' :

add_outil( array(
  'id' => 'citations_bb',
  'auteur' => 'Bertrand Marne, Romy Têtue',
  'categorie' => 'typo-corr',
  'pipelinecode:pre_propre' => '$flux=preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$flux);',
));

C'est ultra simple.

Mais puisqu'il convient aussi de protéger les balises <html>, <code> et Cie, il vaut mieux plutôt écrire :

add_outil( array(
  'id' => 'citations_bb',
  'auteur' => 'Bertrand Marne, Romy Têtue',
  'categorie' => 'typo-corr',
  'pipelinecode:pre_propre' => '$flux=cs_echappe_balises('', 'citations_bb_rempl', $flux);',
  'code:fonctions' => 'function citations_bb_rempl($texte){ return preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$texte); }
',
));

La fonction cs_echappe_balises() protège par défaut les balises html|code|cadre|frame|script.

Enfin, il faut également une chaine de langue dans le fichier
lang/couteauprive_fr.php, histoire de dire à tout le monde de quoi il s'agit (par exemple !!) :

'auteur_forum:nom' => 'Citations bien balisées',
'auteurs:description' => 'Remplacement des balises HTML <quote> par <q> quand il n\'y a pas de retour à la ligne.',

Voila, Bertrand si tu veux bien committer : feu vert !

Pat

P.S.1 : la doc pour ajouter des lames au Couteau Suisse est ici :
[dev] Le Couteau Suisse : développer un outil - SPIP-Contrib
P.S.2 : la doc pour écrire des lames perso est ici :
[dev] Le Couteau Suisse à piloter - SPIP-Contrib

MARNE Bertrand a écrit :

Le 27 mai 2009 18:49, <samy.rabih@free.fr> a écrit :

2 : tu n'as pas tort mais un plugin n'est il pas un peu lourd pour ce genre d'améliorations?

je ne sais pas du tout... ce n'est effectivement qu'un preg_replace
dans un pipeline... Mais comment l'utilisateur normal fait ça ?

Pat2 · Mai 27, 2009, 11:07

Erreur de frappe !
Bien lire :

'pipelinecode:pre_propre' => '$flux=cs_echappe_balises("", "citations_bb_rempl", $flux);',

Pat

Pat a écrit :

Bonjour à tous,

Ceci un excellent sujet de discussion : la différence entre <quote> et <q>...

Voici le code de cette lame du Couteau à placer dans config_outils.php,
en l'absence du fichier 'css/citations_bb.css' :

add_outil( array(
    'id' => 'citations_bb',
    'auteur' => 'Bertrand Marne, Romy Têtue',
    'categorie' => 'typo-corr',
    'pipelinecode:pre_propre' => '$flux=preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$flux);',
));

C'est ultra simple.

Mais puisqu'il convient aussi de protéger les balises <html>, <code> et Cie, il vaut mieux plutôt écrire :

add_outil( array(
    'id' => 'citations_bb',
    'auteur' => 'Bertrand Marne, Romy Têtue',
    'categorie' => 'typo-corr',
    'pipelinecode:pre_propre' => '$flux=cs_echappe_balises("", "citations_bb_rempl", $flux);',
    'code:fonctions' => 'function citations_bb_rempl($texte){ return preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$texte); }
',
));

La fonction cs_echappe_balises() protège par défaut les balises html|code|cadre|frame|script.

Enfin, il faut également une chaine de langue dans le fichier
lang/couteauprive_fr.php, histoire de dire à tout le monde de quoi il s'agit (par exemple !!) :

    'auteur_forum:nom' => 'Citations bien balisées',
    'auteurs:description' => 'Remplacement des balises HTML <quote> par <q> quand il n\'y a pas de retour à la ligne.',

Voila, Bertrand si tu veux bien committer : feu vert !

Pat

P.S.1 : la doc pour ajouter des lames au Couteau Suisse est ici :
    [dev] Le Couteau Suisse : développer un outil - SPIP-Contrib
P.S.2 : la doc pour écrire des lames perso est ici :
    [dev] Le Couteau Suisse à piloter - SPIP-Contrib

MARNE Bertrand a écrit :

Le 27 mai 2009 18:49, <samy.rabih@free.fr> a écrit :

2 : tu n'as pas tort mais un plugin n'est il pas un peu lourd pour ce genre d'améliorations?

je ne sais pas du tout... ce n'est effectivement qu'un preg_replace
dans un pipeline... Mais comment l'utilisateur normal fait ça ?

Pat2 · Mai 27, 2009, 11:21

Pat a écrit :

add_outil( array(
    'id' => 'citations_bb',
    'auteur' => 'Bertrand Marne, Romy Têtue',
    'categorie' => 'typo-corr',
    'pipelinecode:pre_propre' => '$flux=cs_echappe_balises("", "citations_bb_rempl", $flux);',
    'code:fonctions' => 'function citations_bb_rempl($texte){ return preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$texte); }
',
));

Pour ajouter le code CSS que Bertrand a placé dans le fichier css/citations_bb.css, une ligne à ajouter au code ci-dessus :

'code:css' => 'q { quotes: "«" "»"; font-style: oblique; }',

Pat

Pat2 · Mai 28, 2009, 12:03

Pour ajouter une lame perso (lame non intégrable au plugin car trop spécifique à votre site), plusieurs méthodes.

La plus récente (toute dernière révision du Couteau Suisse) : créer un fichier mon_squelette/outils/mon_outil_config.php.

Voici le code des "citations bien balisées" de Bertrand.
Cette lame n'a besoin que d'un pipeline et d'une ligne de CSS.

Donc, un seul fichier suffit :
mon_squelette/outils/citations_bb_perso_config.php

<?php

// Fonction d'ajout de l'outil 'citations_bb_perso'
function citations_bb_perso_add_outil() { return array(
  'auteur' => 'Bertrand Marne, Romy Têtue et moi-même',
  'nom' => '<i>Citations perso bien balisées</i>',
  'description' => 'Remplacement perso des balises HTML <quote> par <q> quand il n\'y a pas de retour à la ligne.',
  'categorie' => 'typo-corr',
  'pipelinecode:pre_propre' => '$flux=cs_echappe_balises("", "citations_bb_perso_rempl", $flux);',
  'code:options' => 'function citations_bb_perso_rempl($texte){ return preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$texte); }',
  'code:css' => 'q { quotes: "« " " »"; font-style: oblique; }',
);}

?>

Le Couteau Suisse reconnaitra instantanément votre nouvelle lame perso que vous pourrez activer/désactiver.
Notez que l'italique du nom permettra de la différencier des autres lames.

Pat

Pat2 · Mai 28, 2009, 12:06

Suite de mon long monologue...
... Et... Ouuups !!

Lire, bien sûr :

'description' => 'Remplacement perso des balises HTML <quote> par <q> quand il n\'y a pas de retour à la ligne.',

Voila ce qui arrive quand on va trop vite !

Pat

Pat a écrit :

Pour ajouter une lame perso (lame non intégrable au plugin car trop spécifique à votre site), plusieurs méthodes.

La plus récente (toute dernière révision du Couteau Suisse) : créer un fichier mon_squelette/outils/mon_outil_config.php.

Voici le code des "citations bien balisées" de Bertrand.
Cette lame n'a besoin que d'un pipeline et d'une ligne de CSS.

Donc, un seul fichier suffit :
    mon_squelette/outils/citations_bb_perso_config.php

<?php

// Fonction d'ajout de l'outil 'citations_bb_perso'
function citations_bb_perso_add_outil() { return array(
    'auteur' => 'Bertrand Marne, Romy Têtue et moi-même',
    'nom' => '<i>Citations perso bien balisées</i>',
    'description' => 'Remplacement perso des balises HTML <quote> par <q> quand il n\'y a pas de retour à la ligne.',
    'categorie' => 'typo-corr',
    'pipelinecode:pre_propre' => '$flux=cs_echappe_balises("", "citations_bb_perso_rempl", $flux);',
    'code:options' => 'function citations_bb_perso_rempl($texte){ return preg_replace("/<quote>(.*?)<\/quote>/","<q>\$1</q>",$texte); }',
    'code:css' => 'q { quotes: "« " " »"; font-style: oblique; }',
);}

?>

Le Couteau Suisse reconnaitra instantanément votre nouvelle lame perso que vous pourrez activer/désactiver.
Notez que l'italique du nom permettra de la différencier des autres lames.

Pat

cerdic · Mai 28, 2009, 6:58

Le 27 mai 09 à 19:11, MARNE Bertrand a écrit :

Le 27 mai 2009 18:49, <samy.rabih@free.fr> a écrit :

2 : tu n'as pas tort mais un plugin n'est il pas un peu lourd pour ce genre d'améliorations?

Pourquoi "Lourd" ?
En quoi la structure plugin serait trop lourde pour une fonction de 3 lignes de code ?

Puisque personne ne répond, et qu'il semble aller de soi que ce genre de fonctionnalité *doit* être dans le cs, je me permet quelques remarques pour tordre le cou à des idées reçues :

- Si 10 plugins independants ajoutent leur CSS comme citations_bien_balisees, le chargement de la page publique sera plus long à cause du nombre de CSS
Faux : le compresseur de CSS disponible dans SPIP 2.0 permet de traiter automatiquement ce problème : les feuilles de styles sont regroupées par media, et concaténée en une seule feuille statique, par média, et stoquée dans local/

- Multiplier le nombre de plugins ralentit SPIP dans les inclusions car le PATH s'allonge pour chaque plugin chargé
Oui par défaut.
Mais un plugin comme

peut très bien s'exclure du path au moyen d'une directive comme
<chemin dir='' version="[;0]" />
qui declare un chemin uniquement pour les versions de SPIP <0
Avec une telle déclaration, un plugin qui n'a pas besoin d'être dans le path ne l'est pas, et ne ralentit pas SPIP

- Multiplier le nombre de plugin qui se branchent sur les pipelines ralentit SPIP
NON, que le même traitement soit réalisé dans 10 fonctions séparées dans 10 plugin, ou tout dans une seule ne ralentira pas le traitement de façon non significative et mesurable

- C'est plus facile de tout mettre dans un plugin unique comme le CS
C'est vous qui voyez. Le CS introduit sa propre api, ses propres systèmes déclaratifs. Coder un plugin indépendant comme l'a fait Bertrand pour une petite fonction est un bon moyen d'apprendre à faire de plus gros plugin. Faire la même chose dans le CS ne permet pas de progresser sur ce point.

- C'est plus pérenne de mettre une fonctionnalité dans le CS
NON
Si il est plus pérenne de développer des gros objets monotlithiques qui font plein de choses différentes que des petites fonctions indépendantes les unes des autres alors oui ...
Mais ce n'est pas vraiment la tendance générale en développement logiciel.
Par ailleurs, faire un plugin indépendant permet une meilleure découpe fonctionnelle, une maintenance et des mises à jour plus faciles (il est possible de corriger et mettre a jour une fonctionnalité sans impact sur les autres).

Il sera toujours plus facile de trouver quelqu'un pour maintenir un petit plugin simple comme citations que le code équivalent noyé dans un gros tout.
Autrement dit, le CS est un concept de développement centralisé, alors que le développement en plein de petits plugins est un concept de développement dé-centralisé collaboratif ou chacun peut adopter un petit plugin à sa mesure et s'en occuper.

- C'est plus facile pour l"utilisateur d'installer un seul plugin que 10
NON
Avec le chargement auto/ depuis SPIP ça devient très discutable.
Par ailleurs, rien n'empeche de faire un flux css 'boite a outils' dans lequel on trouverait toutes ces petites fonctionnalités en plugin indépendants installables directement en auto/

Cédric

klaus · Mai 28, 2009, 8:11

Salut Cédric,

Avec le chargement auto/ depuis SPIP ça devient très discutable.

Est-ce que tu pourrais dire quelques mots de plus sur chargement auto/ ?

Je sais qu'il y un mécanisme pour "auto-updater" les plugins mais je n'ai pas encore compris
- sous quelles conditions il se met en route,
- pour quels plugins il existe et
- comment déclencher un update pour un plugin spécifique (est-ce qu'il y a un bouton sur lequel il faut appuyer ?).

merci, klaus++

19eb0d0ad6f2ebee089f · Mai 28, 2009, 8:16

cedric.morin@yterium.com a écrit :

Par ailleurs, rien n'empeche de faire un flux css 'boite a outils' dans lequel on trouverait toutes ces petites fonctionnalités en plugin indépendants installables directement en auto/

Je suis pas certain qu'on ailles bien loin avec un flux «CSS»... mais bon.

Plus sérieusement je crois que c'est un excellent débat d'idées qui peut naître à Avignon, ou avant, pour comprendre ce qui manque à SPIP dans l'immédiat qui fait que de nombreuses personnes se tournent vers le couteau suisse qui dispose de pleins de gadgets.

Ce n'est pas quelque chose qu'il faut se cacher non plus Cédric :
- le CS est rapide à installer
- est mis à jour fréquemment
- est fonctionnel

Je pense qu'on est au moins d'accord là dessus.

Le fait qu'il ait sa propre API ne me gène pas tant que ça actuellement, mais j'aimerais bien qu'il tende aussi vers autre chose...

Typiquement, si les «q» se retrouvent en lame de couteau (il faut avouer que c'est assez simple à réaliser) nous allons encore nous retrouver avec 2 fois le code sur la zone, et avec tout un tas d'informations dupliquées. Ca en devient agaçant.

Pat ne semble pas avoir la volonté de prendre en compte nos revendications qui ne sont pourtant pas si saugrenues : transformer CS (ou coder un CS2 à côté) qui ne soit pas une duplication du code, mais bien un assemblage de plugins déjà existants. Et hop on installe le CS et hop ça récupère l'ensemble des plugins choisis...

Maintenant, je pense que Pat a codé le CS avec ses connaissances de SPIP et de PHP qu'il avait à l'époque. Comme nous tous il a progressé et doit être plus à même maintenant à pointer les manques actuels de SPIP pour qu'on puisse réaliser cela.

----

Donc, pourrait-on lancer une petite discussion entre aficionados de la Zone sur certains points :

-1) C'est quoi la force du CS actuel ?
-2) C'est quoi ses faiblesses actuelles ?
-3) S'il existait un CS2, comment l'imagineriez vous ?
-4) Qu'est-ce qui manque à SPIP pour le réaliser ?
-5) Techniquement, des idées ?

----

Je réponds déjà moi-même :
1)
- Tout en un
- Centralisation des petites configurations
- Maintenu (une personne)
2)
- Tout en un
- Duplication du code des plugins
3)
- Aggrégateur de plugins (et éventuellement de configurations)
4)
- Meta-plugins ?
5)
- pas encore...

----

Pour ma part, autre sujet, ça me fait penser à STEP (Système de téléchargement d'extensions) que j'avais commencé à coder pour les grottes il y a déjà un an. Ce plugin permet(tait) d'installer automatiquement un plugin ET ses dépendances. Cependant ce système nécessitait que les flux d'informations de plugin (les flux RSS ou paquets.xml) aient connaissance de l'adresse des ZIPs des paquets à récupérer, des préfixes, des numéros de version ET des dépendances (évidemment!).

Or, les flux RSS actuels de SPIP n'ont pas toutes ces infos.

--
MM.

klaus · Mai 28, 2009, 8:33

Salut Matthieu,

- le CS est rapide à installer
- est mis à jour fréquemment
- est fonctionnel

... la dernière mise à jour que j'ai fait m'a fait sauter la page de config des plugins, alors je suis resté àvec une version plus ancienne qui me satisfait. En conséquence je suis POUR du code en double parce qu'il me permet d'installer des fonctions/plugins séparément.

Typiquement, si les «q» se retrouvent en lame de couteau (il faut avouer que c'est assez simple à réaliser) nous allons encore nous retrouver avec 2 fois le code sur la zone, et avec tout un tas d'informations dupliquées. Ca en devient agaçant.

Il faudrait effectivement faire un peu le ménage (_dev, _test et _stable ne signifient pas grand chose actuellement) mais côté utilisateur il suffirais évelopper plugins.spip.net.

Pat ne semble pas avoir la volonté de prendre en compte nos revendications qui ne sont pourtant pas si saugrenues : transformer CS (ou coder un CS2 à côté) qui ne soit pas une duplication du code, mais bien un assemblage de plugins déjà existants. Et hop on installe le CS et hop ça récupère l'ensemble des plugins choisis...

Je répète mon premier argument ...

klaus++

marcimat · Mai 28, 2009, 9:04

klaus++ a écrit :

Salut Matthieu,

- le CS est rapide à installer
- est mis à jour fréquemment
- est fonctionnel

... la dernière mise à jour que j'ai fait m'a fait sauter la page de config des plugins, alors je suis resté àvec une version plus ancienne qui me satisfait.

Tu parles d'une mise à jour de SPIP ou du CS ?

En conséquence je suis POUR du code en double parce qu'il me permet d'installer des fonctions/plugins séparément.

Quel est le rapport ? Je ne comprends pas ?

--
MM.

klaus · Mai 28, 2009, 9:30

Si tu évacues tout code en double de la zone et n'acceptes plus de plugin individuel ayant des fonctions faisant partie du couteau suisse, je suis bloqué dès qu'il y a un problème avec le couteau suisse.

klaus++

Matthieu Marcillaud schrieb:

klaus++ a écrit :

Salut Matthieu,

- le CS est rapide à installer
- est mis à jour fréquemment
- est fonctionnel

... la dernière mise à jour que j'ai fait m'a fait sauter la page de config des plugins, alors je suis resté àvec une version plus ancienne qui me satisfait.

Tu parles d'une mise à jour de SPIP ou du CS ?

En conséquence je suis POUR du code en double parce qu'il me permet d'installer des fonctions/plugins séparément.

Quel est le rapport ? Je ne comprends pas ?

JamesRezo · Mai 28, 2009, 9:38

Le 28 mai 2009 11:30, klaus++ <klaus@spip.de> a écrit :

Si tu évacues tout code en double de la zone et n'acceptes plus de plugin
individuel ayant des fonctions faisant partie du couteau suisse, je suis
bloqué dès qu'il y a un problème avec le couteau suisse.

Ma lecture, certes en diagonale, du mail de Matthieu me fait penser
qu'au contraire, le résultat recherché est de minimiser, et optimiste
qu'il est, de rendre inutile, la duplication DANS le couteau suisse de
code pré-existant dans un plugin de la zone.

klaus++

--
James

azerttyu · Mai 28, 2009, 9:41

S'lt

Si tu évacues tout code en double de la zone et n'acceptes plus de plugin individuel ayant des fonctions faisant partie du couteau suisse,

Je crois klauss que tu vois la reponse à l'envers ce n'est pas de tout
regroupder dans CS que propose matthieu mais le contraire.
Donc en ayant une mutlitude de plugins tres spécifique et un CS qui
fait un habillage cohérent pour le tout.

Par conséquent si CS pete la lame que tu utilses restera fonctionnel
etant donné que le plugin sera autonome.
Si une lame casse le fait de n'avoir qu'un seul code, en une seule
passe de correction tu reperas autant le plugin que son utilisation
dans le CS.

Par conséquent, en ayant ton point de vu, je pense qu'il est
preferable de ne pas avoir de redondances.

Km

eric_tonton · Mai 28, 2009, 10:23

Hello,

Enfin, ce qui me perturbe le plus depuis des mois dans nos discussions autour du CS mais aussi de STEP, c’est, mettre tout et n’importe quoi dans un CS2 ou un meta-plugins n’est pas une bonne chose. Donc en premier, pourquoi le CS n’est pas à mon avis une solution c’est qu’il embarque de la typo, de l’antispam, des fonctions de présentation…

Ensuite, pourquoi le CS est utilisé souvent au détriment des plugins existants (quand ils existent!): pour la bonne raison qu’il rassemble « pleins de fonctions » disponibles et activables à tout moment par le webmestre. En fait, il agit comme une base données dans laquelle on imagine pouvoir puiser à tout moment quand le besoin apparait: c’est donc un peu une zone bis, mais disponible dans l’interface privé de SPIP.

Alors je suis de plus en plus dubitatif sur l’intérêt d’un système de distribution, en tout cas pour proposer une alternative au CS car de toute façon on se retrouverait avec un paquet qui serait toujours un surensemble des besoins utilisateur. Je penche plus aujourd’hui pour un outil intégré à SPIP (ça peut être un plugin) et qui faciliterait l’accès à une fonction hors core.

Si je veux une fonction de typo, il faut que je puisse la rechercher intuitivement, la trouver facilement et l’activer rapidement à partir de l’interface privée. Ca ressemble un peu à STEP mais ça va plus loin car cela nécessite d’organiser les plugins à la base en les catégorisant et en essayant de les spécialiser sur une fonction plutôt que d’intégrer de multiples fonctions connexes dans un même plugin.

Je crois que c’est une piste à creuser absolument mais c’est qu’elle n’est pas uniquement technique…

++
Eric

Le 28 mai 2009 11:41, cam.lafit@azerttyu.net <cam.lafit@azerttyu.net> a écrit :

S’lt

Si tu évacues tout code en double de la zone et n’acceptes plus de plugin individuel ayant des fonctions faisant partie du couteau suisse,

Je crois klauss que tu vois la reponse à l’envers ce n’est pas de tout
regroupder dans CS que propose matthieu mais le contraire.
Donc en ayant une mutlitude de plugins tres spécifique et un CS qui
fait un habillage cohérent pour le tout.

Par conséquent si CS pete la lame que tu utilses restera fonctionnel
etant donné que le plugin sera autonome.
Si une lame casse le fait de n’avoir qu’un seul code, en une seule
passe de correction tu reperas autant le plugin que son utilisation
dans le CS.

Par conséquent, en ayant ton point de vu, je pense qu’il est
preferable de ne pas avoir de redondances.

Km

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

marcimat · Mai 28, 2009, 10:35

Eric a écrit :

Si je veux une fonction de typo, il faut que je puisse la rechercher intuitivement, la trouver facilement et l'activer rapidement à partir de l'interface privée. Ca ressemble un peu à STEP mais ça va plus loin car cela nécessite d'organiser les plugins à la base en les catégorisant et en essayant de les spécialiser sur une fonction plutôt que d'intégrer de multiples fonctions connexes dans un même plugin.

Je crois pas que ça ailles guère plus loin que STEP prévoyait : un champ de recherche dans l'administration des plugins qui renvoie une liste de plugin (adaptés à la version en cours du SPIP).

Sauf que la recherche que j'avais codé était uniquement - de mémoire - dans les plugins présents (et non dans les plugins possibles). Faudrait se repencher sur la question... mais c'est à force de torture de l'esprit (refaire Aptitude pour SPIP n'est pas une mince affaire) que j'avais fini par abandonner. Je n'ai pas essayé de regarder depuis.

Je crois que c'est une piste à creuser absolument mais c'est qu'elle n'est pas uniquement technique....

Oui.

--
MM.

klaus · Mai 28, 2009, 10:38

Apparemment j'ai compris le contraire de ce que vaulait dire Matthieu (!= <> ==)
Ma conclusion est alors qu'il faudra tôt ou tard en finir avec une situation où on a plusieurs systèmes pour la gestion de fonctions supplémentaires (côté utilisateur, je ne parle pas des API).
klaus++

cam.lafit@azerttyu.net schrieb:

S'lt

Si tu évacues tout code en double de la zone et n'acceptes plus de plugin individuel ayant des fonctions faisant partie du couteau suisse,

Je crois klauss que tu vois la reponse à l'envers ce n'est pas de tout
regroupder dans CS que propose matthieu mais le contraire.
Donc en ayant une mutlitude de plugins tres spécifique et un CS qui
fait un habillage cohérent pour le tout.

Par conséquent si CS pete la lame que tu utilses restera fonctionnel
etant donné que le plugin sera autonome.
Si une lame casse le fait de n'avoir qu'un seul code, en une seule
passe de correction tu reperas autant le plugin que son utilisation
dans le CS.

Par conséquent, en ayant ton point de vu, je pense qu'il est
preferable de ne pas avoir de redondances.

Km

RastaPopoulos1 · Mai 28, 2009, 12:13

Le 28/05/2009 12:35, Matthieu Marcillaud a écrit :

Sauf que la recherche que j'avais codé était uniquement - de mémoire -
dans les plugins présents (et non dans les plugins possibles). Faudrait
se repencher sur la question...

C'est assez simple de chercher dans un ou plusieurs RSS à partir du moment où ils fournissent assez d'informations. Donc comme tu avais commencer à l'indiquer, si les listes de plugins possibles sont réorganisées dans ce but, ça ne serait pas trop long de développer ensuite le moteur de recherche.

Donc : quelles informations doivent être ajoutées à l'existant pour pouvoir faire des recherches pertinentes ? (Version, tags indiquant les thèmes, *dépendances*, etc.)

La deuxième étape serait d'ajouter une option (car ça ne doit pas être obligatoire) : "voulez-vous télécharger ET ACTIVER les dépendances en même temps ?".

Avec cette option, plus besoin de meta-plugins... :
- On cherche super rapidement ce qu'on veut (ex : "typo", "spam", etc)
- Tout peut être activer en deux clics maximum : un pour sélectionner le plugin, un pour cocher l'option activant les dépendances, hop

--
RastaPopoulos

d6bcc728454b294b52e0 · Mai 28, 2009, 11:07

Le 28 mai 2009 08:58, cedric.morin@yterium.com <cedric.morin@yterium.com> a écrit :

C’est plus facile pour l"utilisateur d’installer un seul plugin que 10
NON
Avec le chargement auto/ depuis SPIP ça devient très discutable.
Par ailleurs, rien n’empeche de faire un flux css ‹ boite a outils › dans lequel on trouverait toutes ces petites fonctionnalités en plugin indépendants installables directement en auto/

en plus de ce point les raisons qui font que j’utilise le CS sont :

la mise à jour en une fois des différentes petites fonctions que j’utilise , quand tu as 10 petits plugins c’est déjà plus casse pied à moins que j’ai rate une étape sur la mise à jour auto (je suis resté à demander l’install auto d’un plugin dejà installé), donc cette boite à outil devrait incorporer un système de lancement de la mise à jour de l’ensemble des plugins installés.
l’ecran de controle regroupant la conf de l’ensemble des elements actives plutot que n onglets dans config

Quelques idees en vrac pour essayer de faire avancer ce sujet trollesque mais qui presente de mon point de vue un aspect fonctionnel important

creer un « boite a outil » qui se chargerait de gerer le cote « federation » de la gestion de ces petits plugins : recup du flux rss pour l’install auto, centralisation de la gestion des parametres et de la mise à jour. C’est juste un habillage spécifique qui appelle les foncitons du core (et cfg ?).

Faudrait-il le rendre necessaire , ergonomie à voir pour les ecrans de config ?

Prévoir une notion de « categorie »= boite a outil à ajouter dans plugin.xml (pour l’ajout auto du plugin dans le flux rss, ou la detection lors de l’install si elle est faite manuellement)

A+

Arnaud