r13546 - spip/ecrire/public

Author: esj@rezo.net
Date: 2008-12-31 11:48:36 +0100 (mer, 31 déc 2008)
New Revision: 13546

Log:
Je résume: [11390] introduit la gestion des doublons dans les inclusions à l'aide d'un test faux, et trouve utile d'appliquer cette condition ni nécessaire ni suffisante à la gestion des doublons dans les boucles documents en retirant le code qui faisait ça très bien auparavant. [12081] corrige le double bug à l'aide d'une condition suffisante mais non nécessaire, en notant qu'il serait encore mieux d'opérer à l'analyse syntaxique, c'est-à-dire comme fait auparavant. Le présent dépôt rétablit l'ancien code pour les boucles et l'étend aux inclusions. On pourrait rêver mieux comme méthode de développement.

Modified:
   spip/ecrire/public/compiler.php
   spip/ecrire/public/references.php

Details: http://trac.rezo.net/trac/spip/changeset/13546

Je comprends rien au commit mais j'ajoute
que les {doublons} historiques sur documents sont horribles du point de vue perf et utilisation :
- ils necessitent un parsing du texte à chaque calcul
- ils conduisent a des horeurs du genre [(#TEXTE|?{''})] pour pouvoir afficher les boucles avant le texte
- ils sont avantageusement remplacé par le critere {vu=non} qui est calculé lors de la mise a jour en base, donc une fois pour toute.

Cédric

Le 31 déc. 08 à 11:48, esj@rezo.net a écrit :

Author: esj@rezo.net
Date: 2008-12-31 11:48:36 +0100 (mer, 31 déc 2008)
New Revision: 13546

Log:
Je résume: [11390] introduit la gestion des doublons dans les inclusions à l'aide d'un test faux, et trouve utile d'appliquer cette condition ni nécessaire ni suffisante à la gestion des doublons dans les boucles documents en retirant le code qui faisait ça très bien auparavant. [12081] corrige le double bug à l'aide d'une condition suffisante mais non nécessaire, en notant qu'il serait encore mieux d'opérer à l'analyse syntaxique, c'est-à-dire comme fait auparavant. Le présent dépôt rétablit l'ancien code pour les boucles et l'étend aux inclusions. On pourrait rêver mieux comme méthode de développement.

Modified:
   spip/ecrire/public/compiler.php
   spip/ecrire/public/references.php

Details: http://trac.rezo.net/trac/spip/changeset/13546

_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/

Je comprends rien au commit mais j'ajoute

Moi je comprends rien au commentaire du commit

-- Fil

Le 31 décembre 2008 12:23, Fil <fil@rezo.net> a écrit :

Je comprends rien au commit mais j'ajoute

Moi je comprends rien au commentaire du commit

Mais moi je comprends le commentaire du commentaire du commit

Le 31 déc. 08 à 14:38, Matthieu Marcillaud a écrit :

cam.lafit-LQsE5k9MKYjk1uMJSBkQmQ@public.gmane.org a écrit :

Le 31 décembre 2008 12:23, Fil <fil-JM9gtpQu/Ho@public.gmane.org> a écrit :

Je comprends rien au commit mais j'ajoute

Moi je comprends rien au commentaire du commit

Mais moi je comprends le commentaire du commentaire du commit

Moi, ce que j'ai compris, c'est que Emmanuel n'a pas aimé voir une recherche de <INCLURE ou #INCLURE dans la partie compilation de SPIP, alors que chercher ces séquences ne devrait être que dans les public/phraser_*.php (qui analysent la syntaxe et en génère un arbre d'objets pour le compilateur).

Exactement, merci Mathieu.

Il a donc, si j'ai toujours bien compris, modifié le code du compilo pour chercher les inclure ayant des doublons en paramètres directement dans l'arbre généré suite au parsage et transmis au compilateur (et non dans le code du squelette, qui lui peut être différent en fonction du phraseur utilisé.

Sauf "parsage" à la place de "phrasé", c'est là aussi exactement ce que j'aurais écris si tu ne l'avais pas fait:
la syntaxe concrète ne doit apparaître qu'à l'analyse lexicale, ensuite on ne droit travailler que sur la syntaxe abstraite si on veut pouvoir changer la syntaxe concrète (i.e. le langage des squelettes) sans réécrire ce qui est en aval.

Je suppose même qu'il soulève le problème en essayant de produire un second phraseur pour SPIP, pour avoir des squelettes/articles.xml ou je ne sais quoi)

J'en ai un qui tourne en effet depuis un moment, mais je n'ai pas voulu interférer avec la sortie de la 2.0 et il a encore des choses qui me déplaisent. Cela dit j'ai vu le pb pour une autre raison: 11390 avait donc retiré du code bon, qui était utilisé aussi par balise_LOGO_DOCUMENT que mon dépot précédent avait optimisée. Cette fonction contenait donc du code mort depuis 11390, je viens de le ramener à la vie, mais je suis finalement dubitatif sur son intérêt (il remonte à SPIP < 1.8), sa mort provisoire pendant 9 mois n'ayant d'ailleurs ému personne. Si qq trouve un squelette plausible où la situation se produit, je suis preneur.

Bref, beaucoup de suppositions, mais j'admets que je ne comprends pas le texte du commit en lui même.

Bah moi je ne comprends pas que tu puisses dire que tu ne comprends pas, car à mon avis tu as tout compris. :wink:

Par ailleurs, Emmanuel, tu n'as pas mis de commentaires sur la fonction "compile_inclure_doublons($lexemes)" pour expliquer ce qu'elle fait, ce qui me semblerait pourtant utile. Ce qui est certainement une évidence pour toi ne l'est pas forcément pour ceux qui relisent le code !

C'est ce que tu as deviné: elle cherche dans l'arbre de syntaxe abstraite s'il y a au moins un Inclure avec {doublons}.

Committo,Ergo:Sum