Carnet Wiki

Syntaxes Alternatives pour SPIP

Version 12 — August 2009 — goetsu

Objectifs

-  objectif du développement : nouvelle(s) syntaxe(s) pour spip

-  objectif de cette page :

  • collecter et exposer des syntaxes alternatives pour SPIP, ainsi que les réactions et discussions
  • partager la réflexion autour
  • développer la culture de cette/ces nouvelle-s syntaxe-s et en préparer la sortie publique.

Mode d’emploi de cette page participative

-  compléter / améliorer les parties insuffisantes de cette présentation
-  poser questions et réponses dans les parties “Discussion”
-  proposer une nouvelle syntaxe à la fin de cette page


Introduction

-  Allocution conférentielle de ESJ lors de SPIP-Avignon.

Voir la VDO

-  quelques notions clés

ESJ : <? veut dire qu’on quitte l’univers syntaxique dans lequel on était, mais ne préjuge rien sur celui-ci, qui peut avoir des choses en commun avec le nouveau.
Exemple <?php ou <?xml ... ou <?spip

ESJ : SPIP intègre désormais un décompilateur paramétrable des squelettes qui permet de traduire un squelette d’une syntaxe dans une autre...

A propos de XML on lira https://www-licence.ufr-info-p6.jus...

On trouvera une DTD ici : http://www.w3.org/TR/xhtml1/DTD/xht...

Utilité d’une syntaxe XML

Usage d’outils standards : éditeurs; analyseurs.

Lesquels plus précisément ?
Qu’est-ce que ça apporte ?

Discussion

-  Quels sont ces éditeurs et analyseurs qui pourraient valoriser une nouvelle syntaxe ?

-  Est-ce qu’on y gagnerait pas finalement trop peu de chose ? (d’autant plus que la syntaxe envisagée utilise des <?spip ... qui débrancheraient localement l’analyse des éditeurs/analyseurs de XML standards.

-  ESJ: mais c’est justement ce qu’on veut ! Actuellement les squelettes sont considérés comme fautifs par les éditeurs XML justement à cause des instructions SPIP, alors qu’elles disparaissent après compilation.

Par ailleurs, il est possible de définir des plugins pour notepad++ (par exemple) sans que la syntaxe soit XML.

-  ESJ: En théorie on peut toujours tout faire, mais depuis 8 ans que SPIP existe, s’il y a aussi peu de modes d’édition dédié à lui dans les éditeurs standards, il faut en conclure que sa syntaxe ne s’y prête pas.


Critères de Qualité d’une syntaxe

Problèmes actuels à résoudre

-  JLuc : on ne connait pas complètement la syntaxe de SPIP : elle présente des recoins impossibles à documenter car tout ce qui possible ou impossible n’est pas précisément défini (cf ElementsDeGrammaireSpip )

-  ESJ : la syntaxe actuelle est incohérente et lourde. Exemple : [(#arg1|fonctionarg2)] pour appeler une fonction à 2 arguments.

-  ESJ : c’est une syntaxe propriétaire pour laquelle il n’existe aucun outil standard (éditeur, analyseur etc).

à détailler et justifier !

-  ESJ: cette syntaxe n’est comprise par aucun éditeur, qu’y a-t-il à détailler ou à justifier à ce propos ?

Critères de Qualité

Formellement, ESJ évoque 3 niveaux de difficultés d’exigence syntaxique :

-  1. faire reconnaître la structure des boucles par un éditeur standard
-  2. faire accepter le squelette par un éditeur XML (c’est la CONFORMITE XML)
-  3. faire valider le squelette selon une DTD par un validateur XML (c’est la VALIDITE pour XHTML, RSS etc)

Qualitativement, voici une liste de qualités pour un choix de syntaxe :

-  lisibilité
-  simplicité
-  capacité à décrire le langage
-  extensibilité
-  non ambiguité
-  conformité XML
-  validité relativement à la dtd (?)
-  permettre aux colorieurs syntaxique d’améliorer leurs analyse
-  tout ce qui s’ouvre se ferme (parenthèse, crochet, accolade)
-  stabilité des lexèmes
-  stabilité parenthétique
-  existence d’une grammaire écrite qui décrit exhaustivement les syntaxes possibles

...

-  Utilité et nécessité de pouvoir utiliser une nouvelle syntaxe
on manque un peu d’informations là...

Discussion
Quel est l’intérêt du 3ème niveau d’exigence syntaxique ? Ne peut on utilement s’en passer en définissant plutôt une DTD spécifique à SPIP plutôt que d’utiliser celle de XHTML ?

-  ESJ: Les DTD sont des documents officiels du W3C auxquels SPIP (et tous les outils de sa famille) doit se conformer s’il veut produire des pages que les navigateurs sauront afficher. Parler d’“une DTD spécifique à SPIP” est hors sujet: il ne s’agit pas de définir un nouveau format de document pour les navigateurs.


Points concernés

L’API du décompilateur fournit la liste des syntaxes définissant la grammaire spip :

-  format_boucle_*
-  format_polyglotte_*
-  format_idiome_*
-  format_include_*
-  format_champ_*
-  format_critere_*
-  format_liste_*
-  format_suite_*
-  format_texte_*

On détaille les 3 premières ci-après :

-  les boucles

Syntaxe actuelle :

   <B_art>
       <ul>
   <BOUCLE_art(ARTICLES){id_article}>
       <li>#TITRE</li>
   </BOUCLE_art>
       <ul>
   </B_art>
       pas d'article
   <//B_art>

-  les chaines multi

Syntaxe actuelle :

    <multi>[fr] francais [en] anglais</multi>

-  les chaines de langues (idiome) :

Syntaxe actuelle :

   <:plugin:nom:> 
    <:nom{param=valeur}|filtre:> 

Proposition initiale par ESJ présentée à Avignon

-  emploi de <?spip autour de chaque construction SPIP.

-  d’après Marcimat :

   <?spip AVANT art ?>
       <ul>
   <?spip BOUCLE art ARTICLES { (id_article) ?>
       <li>#TITRE</li>
   <?spip } art ?>
       <ul>
   <?spip APRES art ?>
       pas d'article
   <?spip VIDE art ?>

-  d’après Booz :

<?spip AVANT art ?>
  <ul>
<?spip BOUCLE art (ARTICLES) {id_article IN 1,2,3} {  ?>
     <li>#TITRE</li>
<?spip } art ?>
</ul>
<?spip APRES art ?>
pas d'article
<?spip VIDE art ?> 

Discussion

...


Propositions de Simon Camerlo

sur spip-dev le 1er Juillet 2009 :

<boucle attribX="valeur" ... >
   <avant> (...) </avant>


(contenu de la boucle à afficher)


<apres> (...) </apres>
   <sinon> (...) </sinon>
</boucle> 

Discussion

-  ESJ : ça fait des boucles CONFORME XML mais pas VALIDES par rapport à la DTD, et même que ca les empêche définitivement de l’être. Cf pourquoi dans vidéo.

-  Marcimat : oui, j’ai compris aussi cette histoire de validité. exemple simple non valide :
Ici, on ouvre un “ul” mais pour être valide, il ne peut pas y avoir de chevauchement de balise. Cette écriture est donc fausse, comme <a><b></a></b>

<boucle>
   <avant><ul></avant>
   <pendant><li>#TITRE</li></avant>
   <apres></ul></apres>
</boucle>

JLuc : ok, mais ça se corrige (cf prop suivante)


Evolution de la proposition de Simon Camerlo

Suite à la discussion, la proposition de Simon peut évoluer en :

<boucle attribX="valeur" ... >
   <autour>   
        (... contenu à afficher avant)
        <contenu> (...) </contenu>
        (...contenu à afficher après)
    </autour>
   <sinon> (...) </sinon>
</boucle> 

Discussion

-  ESJ : Mais non, la nouvelle syntaxe NE DOIT PAS utiliser des balises <...> sinon il y aura confusion avec celles de la DTD, et la syntaxe ne respecte pas le 3e 3eme niveau d’exigence syntaxique évoqué plus haut.

-  Gilles : (en effet) et ne sont pas dans du XHTML (partie de la DTD qui sera utilisée pas l’éditeur). Le principe de la syntaxe proposée par Emmanuel est de créer un syntaxe xml SPIP qui se base sur cette DTD à l’aide du paramètre “profile” :
content-type : application/spip+xml; profile=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd

-  JLuc : certes, mais on peut définir et utiliser une nouvelle DTD pour un spip XML.

-  ESJ: NON, cf. ci-dessus.


Evolution Alternative Epurée

Cette proposition est une épure de la proposition précédente :

<boucle attrib=valeur...>
        (... contenu à afficher avant)
        <repete> (...) </repete>
        (...contenu à afficher après)
   <sinon> (...) </sinon>
</boucle> 

Simon : c’est beaucoup mieux, en effet. On peut même avoir “repete” optionnel s’il n’y a rien avant ni après (i.e. : s’il n’y a pas de bloc “repete”, on boucle sur tout sauf le bloc “sinon” => écriture encore plus concise)

-  ESJ : par rapport au but visé par le changement de syntaxe, ça ne change rien puisqu’il y a toujours des balises.

- Claude : si je comprends, il faut des caractères ou des combinaisons de caractères qui intuitivement indiquent bien un début et une fin à la pseudo-balise. Il faut aussi que ce soit simple à saisir sans appuyer sur quatre touches simultanément et simple aussi bien pour les claviers Mac que Windows/Linux.

  • Donc un truc du genre :
    !¡boucle:_truc...¡! ; !¡boucle_avant:_truc... ¡! ; !¡multi:[fr] francais [en] anglais¡! ; !¡idiome:plugin:nom¡! ; !¡idiome:nom{param=valeur}|filtre¡! ; !¡inclure{fond1,...}¡! est aussi à proscrire mais donne l’idée (<?spip serait lourd à saisir).