[SPIP Zone] tweaks et compatibilité des traitements

hello,
bon, du coup, j'ai regardé ce plugin, et je decouvre que les traitements sont réalisés en affectant table_des_traitements.
C'est donc incompatible avec toute utilisation de cette global, dommage....

pour empiler les traitements, il faudrait pouvoir produire dans mes_options :
$GLOBALS['table_des_traitements']['TEXTE'][]=$GLOBALS['table_des_traitements']['TEXTE']['']?'decouper_en_pages('.$GLOBALS['table_des_traitements']['TEXTE'][''].')':'decouper_en_pages(propre(%s))';

c'est ligne 181 de tweak_spip :
$temp = "\$GLOBALS['table_des_traitements']['$b'][]='" . join('(', $traitements_utilises[$b]).'%s';
$traitements_utilises[$b] = $temp . str_repeat(')', substr_count($temp, '(')) . "';";
     Mais avec ces histoires de parentheses, je me prend la tete pour generer cette expression.

j'ai fait un truc en 2 temps :
        $temp = "\$tmp=\$GLOBALS['table_des_traitements']['$b']['']?\$GLOBALS['table_des_traitements']['$b']['']:'%s';";
        $temp .= "\$GLOBALS['table_des_traitements']['$b'][]='" . join('(', $traitements_utilises[$b])."'.\$tmp.'";
        $traitements_utilises[$b] = $temp . str_repeat(')', substr_count($temp, '(')) . "';";

mais il y a le probleme de propre qu'il ne faudrait pas passer 2 fois ...

du coup, je me dis qu'il vaudrait peut etre mieux en discuter avant de se prendre la tete...

Qu'en pensez vous ?

Est ce que ca ne devrait pas plutot etre à spip de gerer plusieurs traitements ?

Est-ce qu'il ne faudrait pas plutot construire un apres_propre et le declarer en pipeline ?

Est qu'on peut declarer dynamiquement un pipeline ?

ca dort combien d'heures par nuit un troll ?

@++

spipcarto a écrit :

hello,
bon, du coup, j'ai regardé ce plugin, et je decouvre que les traitements sont réalisés en affectant table_des_traitements.
C'est donc incompatible avec toute utilisation de cette global, dommage....

Spip n'a pas dit son dernier mot...

pour empiler les traitements, il faudrait pouvoir produire dans mes_options :
$GLOBALS['table_des_traitements']['TEXTE']=$GLOBALS['table_des_traitements']['TEXTE']['']?'decouper_en_pages('.$GLOBALS['table_des_traitements']['TEXTE'][''].')':'decouper_en_pages(propre(%s))';

quelle ligne ! d'ailleurs il faut [0] à la place de [''] semble-t-il...
après, bonjour l'ordre de passage pour les plugins...
Si j'ai bien compris, les plugins trifouillent $table_des_traitements dans un ordre pseudo-aléatoire, pouvant s'annuler les uns les autres, puis seulement après, include('public/interface') complète le reste...

c'est ligne 181 de tweak_spip.php :

ligne 192 maintenant !

$temp = "\$GLOBALS['table_des_traitements']['$b']='" . join('(', $traitements_utilises[$b]).'%s';
$traitements_utilises[$b] = $temp . str_repeat(')', substr_count($temp, '(')) . "';";
     Mais avec ces histoires de parentheses, je me prend la tete pour generer cette expression.

j'ai fait un truc en 2 temps :
        $temp = "\$tmp=\$GLOBALS['table_des_traitements']['$b']['']?\$GLOBALS['table_des_traitements']['$b']['']:'%s';";
        $temp .= "\$GLOBALS['table_des_traitements']['$b']='" . join('(', $traitements_utilises[$b])."'.\$tmp.'";
        $traitements_utilises[$b] = $temp . str_repeat(')', substr_count($temp, '(')) . "';";

mais il y a le probleme de propre qu'il ne faudrait pas passer 2 fois ...

du coup, je me dis qu'il vaudrait peut etre mieux en discuter avant de se prendre la tete...

Voici comment les traitements fonctionnent sous tweak-spip :

Chaque tweak déclare un traitement sous la forme :
  'traitement:TITRE:pre_typo' => 'supprimer_numero',
  'traitement:NOM:pre_typo' => 'supprimer_numero',
  'traitement:TEXTE:post_propre' => 'decouper_en_pages',
  'traitement:TEXTE:post_propre' => 'sommaire_d_article',
Et ensuite tweak-spip compile...
L'idée est de considérer que typo et propre sont deux fonctions 'pivot'. Ce pivot est donc rendu obligatoire et un tweak peut insérer sa fonction avant (pre) ou après (post) le pivot. Ca évite donc, spipcarto, de passer propre (ou typo) plusieurs fois...
les termes pre_typo ou post_propre, ça semble inspiré des pipelines mais ça n'a rien à voir...

La somme des trois exemples précédents donne :
$GLOBALS['table_des_traitements']['TITRE']='typo(supprimer_numero(%s))';
$GLOBALS['table_des_traitements']['NOM']='typo(supprimer_numero(%s))';
$GLOBALS['table_des_traitements']['TEXTE']='decouper_en_pages(sommaire_d_article(propre(%s)))';

D'ailleurs, je viens de m'apercevoir que la bonne syntaxe est plutot : supprimer_numero(typo(%s)), non ?

Fil ('Tables des traitements', le 12/04/2007, 23h10) a évoqué la différence entre mes_options et mes_fonctions pour placer ces lignes... Je n'ai pas encore assez étudié la chose ni compris vraiment ce qu'il disait à ce jour.
A suivre...

Qu'en pensez vous ?

Est ce que ca ne devrait pas plutot etre à spip de gerer plusieurs traitements ?

Juste qu'il faut être sûr de comment faire cohabiter plusieurs plugins qui jouent sur les traitements...

Est-ce qu'il ne faudrait pas plutot construire un apres_propre et le declarer en pipeline ?

il me semble que là, on n'a moins l possibilité de cibler le texte sur lequel appliquer une fonction...

Est qu'on peut declarer dynamiquement un pipeline ?

aucune idée. peut-être en manipulant $GLOBALS['spip_pipeline'] dans les options...

ca dort combien d'heures par nuit un troll ?

peu ! un troll qui trolle a moins de temps pour dormir...

Pat

Pat a écrit :

spipcarto a écrit :
  

hello,
bon, du coup, j'ai regardé ce plugin, et je decouvre que les traitements sont réalisés en affectant table_des_traitements.
C'est donc incompatible avec toute utilisation de cette global, dommage....
    

Spip n'a pas dit son dernier mot...

pour empiler les traitements, il faudrait pouvoir produire dans mes_options :
$GLOBALS['table_des_traitements']['TEXTE']=$GLOBALS['table_des_traitements']['TEXTE']['']?'decouper_en_pages('.$GLOBALS['table_des_traitements']['TEXTE'][''].')':'decouper_en_pages(propre(%s))';
    

quelle ligne ! d'ailleurs il faut [0] à la place de [''] semble-t-il...
après, bonjour l'ordre de passage pour les plugins...
  

ben non, on empile dans l'ordre de chargement, c'est la meme logique que pre_propre/post_propre
Mais il faut que les utilisateurs de table_des_traitements pensent à empiler au lieu d'ecraser ce qui est passé avant....

Si j'ai bien compris, les plugins trifouillent $table_des_traitements dans un ordre pseudo-aléatoire, pouvant s'annuler les uns les autres, puis seulement après, include('public/interface') complète le reste...
  

si j'ai bien compris, les fichiers options sont chargés en premier puis, au recalcul, les fichiers fonctions le tout dans l'ordre du path.
L'ordre en gros, c'est /squelettes puis les plugins dans l'ordre alpha puis /ecrire et /dist (la racine y est aussi mais je ne sais pas ou, en premier sans doute)

Donc si qqun utilise table_des_traitements dans ses options de squelette, qu'un plugin ajoute son truc proprement et que tweaks passe derriere, on ne perd rien.
Le seul probleme, c'est propre qu'il faut penser à evacuer pour ne l'avoir qu'une fois en premier.

c'est ligne 181 de tweak_spip.php :
    

ligne 192 maintenant !
  

arg... ca bouge vite !

Voici comment les traitements fonctionnent sous tweak-spip :

Chaque tweak déclare un traitement sous la forme :
  'traitement:TITRE:pre_typo' => 'supprimer_numero',
  'traitement:NOM:pre_typo' => 'supprimer_numero',
  'traitement:TEXTE:post_propre' => 'decouper_en_pages',
  'traitement:TEXTE:post_propre' => 'sommaire_d_article',
Et ensuite tweak-spip compile...
L'idée est de considérer que typo et propre sont deux fonctions 'pivot'. Ce pivot est donc rendu obligatoire et un tweak peut insérer sa fonction avant (pre) ou après (post) le pivot. Ca évite donc, spipcarto, de passer propre (ou typo) plusieurs fois...
  

oui et c'est la que j'ai compris que de toutes facons, ca n'etait pas le lieu pour faire des choses compliquées.
Je prefere pour gerer avant / apres propre poursuivre sur la partie typo de la BTE qui permet d'inserer les regexp correspondante qui seront traitée en une passe plutot que d'empiler des fonctions.
Ca reste très pratique de pouvoir jouer avec la table des traitements, mais pour du traitement systematique, il faut essayer de limiter les passages de regexp.

les termes pre_typo ou post_propre, ça semble inspiré des pipelines mais ça n'a rien à voir...
  

ben au final, c'est presque pareil, sauf que les pipeline permettent d'empiler les traitements alors que table des traitements prend ce qu'il y a dans le tableau et surtout permet de choisir finement à qui on applique.

La somme des trois exemples précédents donne :
$GLOBALS['table_des_traitements']['TITRE']='typo(supprimer_numero(%s))';
$GLOBALS['table_des_traitements']['NOM']='typo(supprimer_numero(%s))';
$GLOBALS['table_des_traitements']['TEXTE']='decouper_en_pages(sommaire_d_article(propre(%s)))';

D'ailleurs, je viens de m'apercevoir que la bonne syntaxe est plutot : supprimer_numero(typo(%s)), non ?
  

si tu veux faire un apres_typo oui, si c'est un avant_typo, c'est bon.

Est ce que ca ne devrait pas plutot etre à spip de gerer plusieurs traitements ?
    

Juste qu'il faut être sûr de comment faire cohabiter plusieurs plugins qui jouent sur les traitements...
  

à chacun de ne pas ecraser ce qu'il y avait avant.
Le mieux ca serait sans doute que l'API fournisse une fonction ajouter_traitement(), mais si tout le monde pense à faire :
$table_des_traitements['TEXTE']=($table_des_traitements['TEXTE'][''] ? 'ma_fonction('.$table_des_traitements['TEXTE'][''].')':'ma_fonction(propre(%s))');

ca marche...

Est-ce qu'il ne faudrait pas plutot construire un apres_propre et le declarer en pipeline ?
    

il me semble que là, on n'a moins l possibilité de cibler le texte sur lequel appliquer une fonction...
  

oui c'est different, mais la, c'est mon besoin (pagination javascript), du coup, je vais faire un plugin pour la BTE

Est qu'on peut declarer dynamiquement un pipeline ?
    

aucune idée. peut-être en manipulant $GLOBALS['spip_pipeline'] dans les options...
  

non, il y a un cache, mais c'est sans importance, on peut avoir un pipeline "vide" et le remplir comme tu fais

Merci pour ces reponses.
Donc en conclusion, tweaks c'est tres bien, il faudrait juste que Spip standardise l'insertion de traitement pour permettre des les empiler sans ecraser et sans repeter propre / typo.
Faire la fonction au niveau du plugin n'a pas de sens, puisqu'elle doit etre utilisée dans tous les cas, il faut vraiment que ca soit l'API de Spip pour que ca puisse marcher.

@++

> D'ailleurs, je viens de m'apercevoir que la bonne syntaxe est plutot :
> supprimer_numero(typo(%s)), non ?

Ah ben non, parce que |supprimer_numero ça sert à supprimer le numéro
qui permet de trier dans MySQL. Et donc il est au début du champ
texte, avant tout traitement typographique.

Par exemple titre = "1. <multi>x[ar]y</multi>"

>> Est ce que ca ne devrait pas plutot etre à spip de gerer plusieurs
>> traitements ?

Oui, je pense aussi qu'il faudra faire une vraie API pour ça ; mais il
faut avoir d'abord une vision claire des besoins, ce n'était pas le
cas lors de l'introduction de avant_propre, puis de
table_des_traitements.

-- Fil

Fil a écrit :

D'ailleurs, je viens de m'apercevoir que la bonne syntaxe est plutot :
supprimer_numero(typo(%s)), non ?

Ah ben non, parce que |supprimer_numero ça sert à supprimer le numéro
qui permet de trier dans MySQL. Et donc il est au début du champ
texte, avant tout traitement typographique.

Par exemple titre = "1. <multi>x[ar]y</multi>"

Oups !!
Je m'étais laissé convaincre par l'article d'Alexandra :
  http://guiderdoni.net/SPIP-1-9-et-supprimer-numero.html
Son exemple est :
  <multi>30. [fr] Astrophysique [en] Astrophysics</multi>
Euh, mais c'est juste ça? Si je regarde de plus près un site allemand par exemple va afficher '30 .', non ?
Quelle est la bonne syntaxe finalement ?

Est ce que ca ne devrait pas plutot etre à spip de gerer plusieurs
traitements ?

Oui, je pense aussi qu'il faudra faire une vraie API pour ça ; mais il
faut avoir d'abord une vision claire des besoins, ce n'était pas le
cas lors de l'introduction de avant_propre, puis de
table_des_traitements.

+1
cette table est un réel outil pour mieux cibler les actions d'un plugin sur le texte.
s'inspirer des branchements des pipeline est une piste. un avant/après une fonction pivot, peut-être ?
Le mécanisme de compilation des traitements que j'ai adopté dans tweak-spip vous parait-il trop compliqué?

Pat