[spip-dev] A propos des modes d'interprétation des squelettes

Dev
1

Bonjour,

je m’immisce dans la conversation, avec une question naïve.

2009/9/8 Fil <fil@rezo.net>
(sujet : [spip-dev] Débuggueur de 2.1 légèrement trop puissant !)

Bien d’accord sur ce principe, mais ce n’est pas ça que tu proposes: tu
proposes une fonction qui ne permettra pas au développeur du plugin de
repérer une vraie erreur.

Mais non. Je propose juste que ça ne nous saute pas à la gueule tant
qu’on ne le demande pas. Un mode « non strict ». Tu peux très bien faire
aussi un mode « strict » qui dénonce tout, mais sans l’imposer par
défaut, afin de ne pas empêcher ceux qui bossent aussi de leur côté
sur d’autres aspects et problèmes, et que tu obliges actuellement à se
concentrer sur ta problématique du moment.

Ne pourrait-on pas garder la possibilité de faire une précompilation des squelettes, pour les passer en mode « strict » ?

La chose à laquelle je pensais était de pouvoir :

  • En mode « transitoire », pouvoir garder l’ancienne syntaxe, avec tous les problèmes que cela peut poser.
    (mais pour bien des squelettes, c’est largement satisfaisant)
  • En mode « transitoire strict », rendre une pré-compilation possible.
    Cela obligerait à pouvoir suivre cette phase dans un validateur accessible depuis l’interface privée afin d’en étudier les erreurs.
    L’idéal alors serait que l’on puisse mélanger l’ancienne et la nouvelle syntaxe.
  • En mode « strict » ne garder que la nouvelle syntaxe (on écrirait alors dans le langage pré-compilé).
    La validateur des squelettes relèverait alors toutes les erreurs de syntaxe qui rendraient l’interprétation incohérente.

Le parallèle évident est la présence de ces 3 modes dans la spécification HTML 4.01 et celle du XHTML1.0
Même si c’est « mieux » de coder en XHTML Strict, les sites en HTML simple passent encore…

Heureusement, non ?

2

Bonjour,

je m'immisce dans la conversation, avec une question naïve.

...

   L'idéal alors serait que l'on puisse mélanger l'ancienne et la nouvelle syntaxe.

Cette "conversation" n'est pas une problème de syntaxe tournant autour de ce que j'ai présenté à Avigon pour du long terme,
mais de sémantique, avec les modifs du débusqueur de la 2.1. La nouveauté avec le dépot dont il est question, est que le compilateur émet une erreur lorsque qqch (identifiée par l'analyse syntaxique comme devant être une fonction PHP) n'est pas définie, alors qu'avant le compilateur produisait du code dont l'exécution provoquera ce message. Ce retard dans l'émission de ce message est une sémantique préjudiciable à l'aide à la mise au point, ainsi qu'aux performances. Il faut choisir entre l'un ou l'autre de ces comportements, on ne peut les "mélanger" car l'un garantit l'absence d'erreur de fonction indéfinie à l'exécution, mais cette garantie disparaît dès qu'on le mélange à l'autre comportement.

La question est de savoir comment faire évoluer de l'ancien au nouveau comportement: erreur brutale, réécriture sans rien dire (avec perte de la garantie ci-dessus), avertissement (sur la page ou dans les logs) que ça doit être réécrit manuellement. La première méthode est la plus simple à faire, c'est celle que j'ai retenue au moins provisoirement.
Il faut bien voir que le pb ne concerne PAS tous les squelettes utilisant un filtre de plugin, mais seulement ceux prévus pour fonctionner en bi-mode (plugin dispo ou pas) dans l'utilisation de ce filtre. Il y en a combien ? Assez peu je pense, mais je peux me tromper.

Committo,Ergo:Sum