Salut Christian,
Les squelettes 1.6 font 0 faute mais je n'ai pas encore inclu
le support de <INCLURE> et <:...:> (parsé mais pas généré)Pour ceux qui ont des squelettes bien violents et un peu de temps,
merci de me dire ce que ça donne.
Si quelqu'un a un php3 aussi, j'aimerais savoir si c'est bien
compatible.Dernier détail : si les gardiens de la flamme peuvent donner leur
avis sur la question à l'occas ...
j'ai jeté un coup d'oeil à ton truc (non, non, les développeurs
spip ne traitent pas les contributeurs par dessus la jambe !).
j'ai fait quelques modifs à fins de test et t'envoie les fichiers
modifiés ci-joint.
Remarques en vrac :
- heu, peux-tu régler ton éditeur pour indenter avec des tabs ?
- ton parser a un problème majeur : il accroche sur des
caractères spécifiques plutôt que de chercher les structures
directement (oui, je sais, c'est comme ça qu'on fait (tm),
mais bon)
- du coup, il est lent puisque le chevron "<" est très utilisé
en HTML...
- on le rend beaucoup moins lent en utilisant preg_match (note
que le parser de spip lui, s'en passe plutôt bien, et que
preg_match n'est pas toujours dispo sous php3...)
- d'autre part, toujours à cause du problème susnommé, tu
dois gérer une espèce de backtrack pour retrouver les textes
conditionnels avant
- bugs potentiels : que se passe-t-il si j'écris
(#EMAIL) ? ce n'est pas un champ étendu, c'est juste un
champ que je veux afficher entre parenthèses
En fait je pensais adopter (dans l'éventualité où je bougerais
ma flemme et écrirais moi-même un tel machin) une méthode
plus adaptée à SPIP, c'est-à-dire :
- pas de langage de grammaire générique (enfin on peut,
mais pour SPIP ce n'est pas utile vu le peu de structures
différentes)
- plutôt qu'un tableau de regexp, écrire une classe de
parsing dédiée pour chaque structure (class ParserChamp,
class ParserBoucle, etc.)
- dans chaque classe Parser*, une fonction match() écrite
à la main qui trouve la première occurence du type de
structure traitée, et renvoie sa position dans le buffer
(ou -1 si pas trouvé)
- à chaque itération, on choisit la structure qui a
la première position dans le buffer
Avantage 1 : on matche directement sans chercher des
caractères à accrocher.
Avantage 2 : les fonctions match() étant écrites au cas
par cas, elles sont adaptées à la type de structure
traitée et effectuent la détection correctement. Notamment,
renvoyer pour les boucles l'index du <B_toto> plutôt
que du <BOUCLE_toto> (note que le parser actuel, en
bidouillant un peu, pourrait déjà résoudre ce bug),
et aussi éviter les histoires de backtrack.
Quant au nombre de match() que cela entraîne, il n'est
pas si élevé que ça, et peut-être que les résultats d'un
match() précédent peuvent être mis à profit s'ils n'ont
pas été consommés tout de suite. De plus rien n'empêche
de les optimiser (voir par exemple utilisation de strpos
dans la détection de boucles du parser actuel), ce qui
est beaucoup plus difficile avec une abstraction du
matching dans la grammaire "générique".
a+
Antoine.
modif.tgz (7.02 KB)