Hello
Je réponds à toute les questions par un seul mail.
D'une part j'ai mis sur le site de SVP
http://spip21.smellup.net/spip.php?article17
un article reprenant le contenu du diaporama présenté avec spip-S5 à Avignon en 2009. C'est le texte initial (moins qq fautes d'orthographe) mais j'ai galéré pour passer de l'un à l'autre car il y a eu un dégradation dans les dump de SPIP: il transforme excessivement les < en &lt; etc ça pète tous les textes comme celui-là où on veut montrer du code. Au passage c'est un autre exemple de mauvaise qualité de SPIP en matière de la syntaxe. Je crois que j'ai tout rétabli, n'hésitez pas à signaler des scories éventuelles. Kent1, ce serait bien, si tu ne peux remettre sur pied video-spip, d'attacher à cette article la video correspondante.
Le code de SPIP prévoit que les fichiers de squelettes ont une extension indiquée par le constante EXTENSION_SQUELETTE, pour l'instant toujours définie à "html". Si la distribution officielle de SPIP passe un jour à une autre extension (reflétant bien sûr un changement de syntaxe) en changeant la valeur de cette constante, on a deux scénarios possibles en tant que développeurs, qui impliquent chacun 2 scénarios pour les auteurs de squelettes.
Premier scénario, on ne change rien d'autre au code. Les auteurs de squelettes ont alors deux choix:
- en faire un maximum en appliquant sur leurs propres squelettes le traducteur qu'on leur fournira. Dans plus de 99% des cas ça marchera sans intervention manuelle, il leur faudra juste, quand ils voudront continuer à développer leur code, s'habituer à cette réforme de l'orthographe. Mais le but est justement qu'ils puissent utiliser le mode XML des éditeurs de texte, ça aidera.
- en faire un minimum en remettant "html" comme valeur d'extension. S'ils n'utilisaient AUCUN des squelettes std, ça marchera et ils profiteront des autres nouveautés des nouvelles versions de SPIP. S'ils en utilisaient, il leur faudra aller les chercher dans la version précédente et ça devrait marcher aussi, ils perdront juste les améliorations éventuelles dans les squelettes en nouvelle syntaxe.
Deuxième scénario: on améliore le code pour qu'il puisse SIMULTANEMENT accepter deux syntaxes. En gros, c'est remplacer les qq endroits où on fait
find_in_path($fond. EXTENSION_SQUELETTE)
par un code qui, si ce premier appel échoue, va essayer un 2e find_in_path sur la vieille extension "html" et en cas de réussite va appeler l'ancien analyseur.
Je dis "en gros" parce que dans parametrer/styliser le find_in_path est un peu caché, il y a un peu de réécriture à faire mais ce n'est pas un gros chantier.
Pour les auteurs de squelettes, ils profitent de toutes les nouveautés, peuvent traduire leur squelettes maintenant ou plus tard, sachant qu'il y aura une perte de temps à l'exécution si le 2e find_in_path est nécessaire.
Puisqu'on parle de perf, la discussion sur les perfs des modifs de l'analyseur syntaxique me parait assez oiseuse: la compilation n'a pas lieu souvent et les modifs invoquées sont négligeables, c'est un faux problème. Ce qui est en jeu c'est le temps d'apprentissage de la nouvelle syntaxe par chacun, avec le risque de rejet bien connu dans l'histoire des réformes de l'orthographe. Quant à vouloir rationnaliser l'existant, ce serait une totale perte de temps.
Enfin, sur le caractère inachevé de ce que j'avais exposé, j'avais effectivement donné seulement un cadre général à discuter, en montrant en revanche que l'outil de migration était, lui, parfaitement achevé. Mais il faut bien voir que ce cadre général fixe vraiment peu de chose: il dit seulement ce qu'il faut faire pour avoir la conformité XML (et discute un peu la possibilité d'avoir la validité, mais ça n'est pas obligatoire). A l'intérieur du cadre on peut soit essayer de rester au plus près de l'ancienne syntaxe, soit profiter de l'occasion pour aller plus loin (par exemple autoriser à écrire du SQL pur plutôt que la structure en "criteres" de SPIP qui mélangent les différentes clauses SQL). Je n'ai pas vraiment d'avis sur la question pour le moment.
Ah, encore une chose: la doc sur spipnet. J'avais regardé tous les exemples et par bonheur ils sont repérables par seulement 2 RegExp MySQL. Je pense que le bon plan est d'en faire des fichiers .txt à part, et de leur appliquer l'outil de migration pour avoir un 2e jeu de fichiers, d'extension .spip. Ensuite,
on remplace le texte dans le corps des articles par un modèle d'incrustation utilisant un bout de JavaScript permettant de visualiser l'un ou l'autre ou les deux fichiers référencés par le modèle.
J'espère avoir répondu à tout.
esj
