Re: SPIP nu

Hello

Bravo pour cette concrétisation !
Ça semble pouvoir faire ce qu'il faut
et ça semble assez simple pour pouvoir être robuste.

Le mélange de SPIP et de php semble toutefois un peu contreproductif :
si on est en php autant introduire directement la structure php ! (au bon endroit)
- sauf que c'est très compliqué d'écrire des critères en php
alors que les critères sont si faciles à écrire en SPIP (comme dans ton code).
C'est pas forcément le seul endroit avec ce mélange des genres
mais là c'est particulièrement flagrant.

Alors pour rester 100% SPIP et simple, j'imagine une extension du compilateur
qui permette de générer les appels à ce pipeline à partir d'un code SPIP.
Càd que le compilateur comprendrait une nouvelle instruction
qui serait compilée sous les formes que ton code a introduit.

Imaginons que ce soit une balise #ETENDRE

Dans le plugin mots, il y aurait :
[(#ETENDRE{boucle=_liste_art}{sourcefile=../prive/objets/liste/articles.html}
         {id_mot?})]

Dans organiseur, il y aurait :
[(#ETENDRE{boucle=_enligne}{sourcefile=../prive/objets/liste/auteurs_enligne.html}
         {imessage!=non}{en_ligne>#VAL{Y-m-d H:i:s}|date{#VAL{-15 minutes}|strtotime}}{!par en_ligne})]

Ça suffit pour tes exemples, dans lesquels un plugin introduit des critères supplémentaires.
C'est lisible, facile à comprendre et à écrire,
et ça semble carrément naturel d'écrire du SPIP en SPIP et non en php.

Dans l'absolu, on ne peut pas faire avec cette syntaxe
tout ce qu'on peut faire en php
et notamment éditer les critères pré-existants, si jamais il le fallait.
Mais si c'est utile il pourrait y avoir des modificateurs :
- {supprimer} pour carrément supprimer les critères préexistants,
avant d'en ajouter de nouveaux.
- {remplacer val1, val2} pour remplacer val1 par val2 dans les critères préexistants
Mais ça devient plus compliqué et c'est pas nécessaire dans les cas simples comme ceux cités...

Ah, et pour finir : je ne sais pas quand ou quel mécanisme compilerait ce fichier spip
de déclaration d'extensions...
Si ça se faisait, on pourrait potentiellement mettre dans ce fichier plein d'autres déclarations qui ainsi ne devraient 
plus se faire en php.
Ce serait un pré-squelette comme il n'en existe pas encore à ma connaissance ; ça serait compilé automatiquement, avec 
un cache, ou bien dans l'interface privée il y aurait un bouton "Compiler les déclarations".

JL



Le 24/05/2016 08:49, James a écrit :
> Salut,
>
> Un patch (non, 3) donc, mais pas pour un critère {pipeline} parce que finalement, ça me plaisait pas trop.
>
> ici, j'introduis un pipeline 'inserer_criteres' qui permet d'injecter des critères avant que le compilateur ne démarre
> son analyse. Ce qui permet de coder des insertions à l'aide de chaine de caractères (ex: "{id_mots?}" plutôt que de
> construire des instances de l'objet Critere, parce que c'est cauchemardesque :-)
>
> Exemple exhaustif avec les plugins mots et organiseur.
>
> Amitiés,
>
> Le 8 mai 2016 à 00:25, James <[email protected] <mailto:[email protected]>> a écrit :
>
>     Je viens de faire l'essai. J'ai codé un critère {pipeline} qui appelle un pipeline inserer_critere, remplacé
>     {id_mot?} dans la boucle "_liste_art" par ce critère et ajouté une fonction dans le plugin mots qui insère le
>     critère {id_mot?} via le pipeline. Et ça marche.
>
>     Le truc, tel que je l'ai codé, c'est que ce critère {id_mot?} sera inséré dans absolument toutes les boucles qui
>     exploiteront {pipeline}. On pourrait limiter aux seules boucles ARTICLES, ou ARTICLES+RUBRIQUES, par exemple. mais
>     ça sera appliqué quand même à toutes les boucles ARTICLES (ou ARTICLES+RUBRIQUES) et on ne le souhaite pas forcément...
>
>     De même, si un autre plugin utilise le pipeline inserer_critere, pour ajouter son critère, on se retrouve avec 2
>     critères ajoutés systématiquement à toutes les boucles... et on ne le souhaite pas forcément, non plus ...
>
>     Et je ne suis pas certain que d'ajouter un paramètre soit judicieux : {pipeline truc} qui n'appliquerait que les
>     critères qui s'enregistrent dans "truc", je n'y crois pas beaucoup.
>
>     Bref, je crois que soit il manque quelque chose à ce concept, soit que ce n'est pas le bon.
>
>     Mais je fournis le patch si vous voulez.
>
>
>     Le 7 mai 2016 à 18:00, Eric Lupinacci <[email protected] <mailto:[email protected]>> a écrit :
>
>         Yo,
>
>
>         Le 7 mai 2016 à 17:48, James <[email protected] <mailto:[email protected]>> a écrit :
>
>
>             Pour l'histoire des critères, j'ai plus de mal ...
>
>
>         On pourrait pas imaginer un meta critère {pipeline} dans une boucle qui indiquerait qu'on ouvre un point
>         d'entrée dans cette boucle pour y insérer des critères additionnels ?
>         Et dans le plugin on déclarerait un pipeline inserer_critere par exemple ou l'on donnerait suivant une syntaxe à
>         définir les éléments du critère ?
>
>
>         ++
>         Eric
>
>
>
>
>     --
>     James
>
>
>
>
> --
> James
>
>