Carnet Wiki

Syntaxes Alternatives pour SPIP

Version 17 — September 2009 JLuc

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|fonction{arg2})] 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 ...

ESJ : Je pense que le langage des squelettes a eu une évolution comparable à celle de HTML.
Au début qqch au but précis et clair, puis des ajouts dans tous les sens débouchant sur un langage trop riche,
dont ensuite la sémantique a été heureusement coupée en deux par le couple HTML4/CSS
et dont la syntaxe a été heureusement homogénéisée par XHTML 1.0.

Je pense que nous devons entamer une évolution similaire, qui ne serait qu’un aspect de l’allègement du noyau avec lequel nous sommes tous d’accord,
en procédant ainsi: dans le noyau limiter la signification de # à l’extraction d’un champs SQL, et déporter toutes les balises SPIP dans des plugins.
Et tant qu’à faire, ne pas passer par l’étape HTML4 mais aller directement à l’étape XHTML, en rendant la syntaxe compatible XML.
Cela redonnera à SPIP sa simplicité originelle accueillante pour les néophytes, qui découvriront ensuite petit à petit le fonctionnement technique
des seuls plugins dont ils auront besoin, plutôt que de devoir tout ingurgiter d’un coup.

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:> 

Eléments de la proposition Proposition initiale de par ESJ, présentée à Avignon

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

ESJ: Non, attention, c’est seulement pour les boucles que ce marque de “processing instruction” est indispensable, afin d’éliminer les pseudo-balises BOUCLE, B, /B etc. Pour la pseudo-balise MULTI,
je propose d’utiliser #, pour la pseudo-balise INCLURE il y a plusieurs solutions.

-  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

Cette proposition , faite sur spip-dev le 1er Juillet 2009, ne porte que sur la syntaxe des boucles :

<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 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

JLuc : 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)

<boucle attrib=valeur...>
        (...contenu à répéter)
   <sinon> (...) </sinon>
</boucle> 

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

-  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).

ESJ: Dans la vidéo je donne des règles d’abréviations qui font que <?spip apparaîtrait en fait peu souvent: mes tests sur tout le répertoire squelettes de la zone montrent que la taille des squelettes ne varierait que de qq pourcents, et parfois à la baisse.


Commentaire de Philippe Philippe Daix

Je sais pas si il est approprie pour moi d’editer cette page mais bon je me lance.

Je suis utilsiateur avance, mais non programmeur et je doit dire que le language de boucle tel qu’il est actuellement a certaine limites mais il offre un reel avantage pour des personnes comme moi.
_ Je pense que les utilisateurs qui veulent aller plus loin on toujours le choix d’aller coder des trucs grace aux balises additionelles, mes_fonctions, mes_options et les plugins.
_ J’espere juste qu’on gardera le system de boucle initiale autant que possible car c’est purement genial pour les novices qui veulent aller un peu plus loin sans apprendre php.
_ Quand je regarde les propositions plus haut, j’ai peur :)
Enfin juste le conseil d’un fan de SPIP depuis la 1.
3 :)
Phil

Je pense que les utilisateurs qui veulent aller plus loin on toujours le choix d’aller coder des trucs grace aux balises additionelles, mes_fonctions, mes_options et les plugins.

J’espere juste qu’on gardera le system de boucle initiale autant que possible car c’est purement genial pour les novices qui veulent aller un peu plus loin sans apprendre php.

Quand je regarde les propositions plus haut, j’ai peur :)

Enfin juste le conseil d’un fan de SPIP depuis la 1.3 :)

Phil

ESJ: Deux réponses:

1. La syntaxe actuelle sera toujours acceptée par les versions ultérieures de SPIP, le compilateur de squelettes étant prévu pour accepter plusieurs syntaxes simultanément.

2. Il faut visionner la vidéo pour bien comprendre les enjeux, et en quoi un changement de syntaxe est en définitive quelque chose d’assez superficiel. Je pense que beaucoup de balises introduites dans les dernières versions de SPIP (#SET par exemple) sont beaucoup plus problématiques pour les non programmeurs que ce qui est présenté dans cette vidéo.