[spip-dev] Réflexion sur un changement de syntaxe des squelettes SPIP

Bonjour à tous,

Emmanuel nous a présenté à Avignon un premier exemple d'évolution de la syntaxe SPIP pour quelle devienne - entre autre - non destructrice d'une validité XML du squelette. Pour résumer beaucoup, la syntaxe actuelle des boucles pose problème car il y a parfois des balises (au sens HTML) ouvertes mais non fermées (<B_article>) ou fermées mais non ouvertes (<//B>) ou ne respectant pas ce qui est attendu (attribut="valeur") dans une balise.

A son stade de réflexion, il propose de modifier l'écriture des boucles, des multi (en squelettes) et des chaines de langues.
La syntaxe proposée pour les deux derniers me parait appréciable :

Actuelle des multi (polyglotte) :
    <multi>[fr] francais [en] anglais</multi>
Proposition :
    #:{[fr] francais [en] anglais}

Actuelle des langues (idiome) :
    <:plugin:nom:>
    <:nom{param=valeur}|filtre:>
Proposition :
    #:plugin:nom
    [(#:nom{param=valeur}|filtre)]

Pour les boucles la syntaxe proposée tient compte de certaines contraintes qu'il faut connaître :
- tout ce qui s'ouvre se ferme (parenthèse, crochet, accolade)
- doit etre valide XML
- si possible doit permettre aux colorieurs syntaxique d'améliorer leurs analyse
- pour sa première proposition il ne souhaitait pas modifier profondément l'écriture des boucles telle qu'on les connait, cherchant à modifier le moins possible de choses.

Son résultat est approximativement de remplacer "<" de <BOUCLE par <?spip et le ">" par ?> ce qui crée plusieurs avantages :
d'un point de vue XML, c'est une syntaxe qui devient valide ; on modifie peu de chose, ce qui peut donner :

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

Proposition (qui a déjà évoluée je crois mais c'est ce qui a été présenté - de mémoire)
   <?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 ?>

Je crois me souvenir que dans le topo réticulaire que nous a présenté Emmanuel en avant première à Avignon, la solution qui retablit la stabilité des lexemes de SPIP et arrange sa stabilité parenthétique est plutôt la suivante :

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

Sinon je relis ton mail pour bien comprendre, mais je voulais préciser celà avant que ca ne troll de partout.

Voilà qui va pousser Esj à publier sa prez plus vite que prévu ^^.

BoOz

marcimat@free.fr wrote:

Sinon je relis ton mail pour bien comprendre, mais je voulais préciser celà avant que ca ne troll de partout.

oui, évitons de troller inutilement sur des oui-dire !
On a le temps d’en discuter tranquillement, hein … Attendons donc déjà qu’emmanuel publie sa présentation, qui n’est de toute façon, pour l’heure, qu’un état de reflexion, pas une proposition finie ficelée.
Comme il l’a bien précisé, il reste des problèmes à résoudre.

Cédric

Bonjour à tous,

Emmanuel nous a présenté à Avignon un premier exemple d'évolution de la syntaxe SPIP ...

Hum, comme le disent Booz et Cédric dans les mails suivants, ce qui était important dans ma présentation c'était l'énoncé des pbs qu'il me semble important de résoudre, et juste la démonstration que j'ai développé les outils pour permettre une migration en douceur de l'existant, il m'a bien fallu prendre une syntaxe nouvelle pour monter que ces outil marchaient, mais tout reste ouvert.

Par ailleurs, il est un peu fallacieux de déplorer une lourdeur d'écriture en ne prenant que la syntaxe de base dont j'ai bien dit qu'elle admettait des abréviations selon des règles logiques faciles à appliquer: il ne faut vraiment pas effrayer tout le monde avec une vision tronquée de ce que j'ai exposé.

Par ailleurs, tu fais une faute de logique ici:

- <?spip ne se comporte pas comme d'autres langages <?xml ou <?php ou d'autres encore car il ne veux pas dire qu'il y aura du SPIP uniquement dans cette partie la du code et pas ailleurs :

<? 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. Du coup, je trouve la problématique de ton mail globalement mal fondée.

Autre approximation dans ton mail:

- c'est valide XML puisqu'il n'y a plus de < ou de > dans l'écriture des boucles

Non, c'est une condition nécessaire mais non suffisante, tu oublies tous les autres problèmes dont j'ai parlé dans la 4e partie.
Et si tu renonces aux <?spip ... ?> ils seront beaucoup plus fréquents.

J'avais cru comprendre que Quentin mettrai en ligne rapidement la video de ma présentation. S'il y a problème, j'ai une copie.
Il vaudrait mieux que chacun la visionne, sinon ça va partir en troll sans possibilité de converger.

Emmanuel

S'lt

J'avais cru comprendre que Quentin mettrai en ligne rapidement la video de
ma présentation. S'il y a problème, j'ai une copie.
Il vaudrait mieux que chacun la visionne, sinon ça va partir en troll sans
possibilité de converger.

Pour la presentation il est possible de l'integrer sur s5.scriibe.net
, si tu peux nous fournir un dump rubrique.

Km

Pour converger sans troller, on vient de mettre en ligne provisoirement les slides avec l’audio en attendant le montage définitif de l’intervention d’ESJ.
Bonne écoute et bon visionnage
http://videos.spip.org/spip.php?article113
Alexandra

Attention, ce n’est qu’une version provisoire.
Une version plus sympa (on avait 2 caméras, on va faire un montage vidéo) est prévue.
Idem pour les autres ateliers.

De plus, des versions HD seront disponibles, ce qui rend les vidéos plus confortables.

Donc patience, attendez encore un peu…

.Gilles

Mille mercis Alexandra !!!!

Emmanuel

Alexandra Guiderdoni wrote:

Bonne écoute et bon visionnage
http://videos.spip.org/spip.php?article113

Ah magnifique !
Je regrettais ne ne pas pouvoir être avec vous.
merci, Paolo

+1

pierre

Euh, c’est moi ou il n’y a que le début ?
Ca coupe à 8 minutes quand ça commence à devenir intéressant… :frowning:
Dommage, va falloir patienter (bon courage pour le montage).

Simon

Alexandra Guiderdoni a écrit :

Emmanuel Saint-James a écrit :

ce qui était important dans ma présentation c'était l'énoncé des pbs qu'il me semble important de résoudre, et juste la démonstration que j'ai développé les outils pour permettre une migration en douceur de l'existant, il m'a bien fallu prendre une syntaxe nouvelle pour monter que ces outil marchaient, mais tout reste ouvert.

Oui j'ai oublié de parler de ça (le principal !) et je m'excuse de ma précipitation.

Du coup, je trouve la problématique de ton mail globalement mal fondée.

Possible oui.

Sinon, je ne vois pas où dans la référence de XML il est dit que le contenu des attributs doit être du texte uniquement ?

Peut on écrire <x attr="id_rubrique=[(#ID_SECTEUR)]"> par exemple ?

Il y a du coup une exploration possible :
<boucle:nom table="RUBRIQUES (id_rubrique=[(#ID_SECTEUR)], id_article ?)">

</boucle:nom>

Bon, pas d'affolement... :slight_smile:

Sinon, Carcassonne est une belle ville !
Ciao.

je ne vois pas où dans la référence de XML il est dit que le contenu des attributs doit être du texte uniquement ?

Peut on écrire <x attr="id_rubrique=[(#ID_SECTEUR)]"> par exemple ?

Je ne suis pas sûr de comprendre la question. On met ce qu'on veut dans un attribut, simplement un analyseur XML n'inteprétera pas les éventuels chevrons qui s'y trouvent comme dénotant une balise.

Il y a du coup une exploration possible :
<boucle:nom table="RUBRIQUES (id_rubrique=[(#ID_SECTEUR)], id_article ?)">

Et comment fais-tu lorsque tu veux utiliser des guillemets dans un critère (typiquement {"<br />"} ou {", "} très fréquents) ?

J'ai l'impression que le point d'achoppement autour de la nouvelle syntaxe se résume à "faut-il assumer qu'un squelette mixe 2 syntaxes ou pas", c'est-à-dire que la syntaxe actuelle écrit la structure de boucle d'une manière très ressemblante à du HTML, tandis que ce que je propose est de dissocier nettement les deux. Ne pas mentir sur une réalité que tôt ou tard on finira par apprendre me paraît préférable, d'autant que les squelettes ne s'emploient pas que pour les langages de balisages.

Il y aura évidemment un gros effort pédagogique à faire si on change de syntaxe, mais je suis prêt à le faire et il me parait en valoir la peine.

Committo,Ergo:Sum

Suite à ce que j'ai pu voir de la vidéo et ce qui a été dit cans les messages précédents, voici une petite suggestion concernant les boucles "avant que ça trolle" (c)
Ca fait un moment que j'ai ça en tête, pourquoi pas prendre une syntaxe du type ci-dessous qui rendrait les boucles valides xml (au moins pour l'ouverture / fermeture des tags et les passages de paramètres) :

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

    (contenu de la boucle à afficher)

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

Ca me rappelle 10 (douloureux) mois à coder des moulinettes xslt, mais ça pourrait macher sans *trop* changer les habitudes des gens, non ?

Mes deux sous dans le débat.

    Simon

Committo,Ergo:sum a écrit :

parce que c'est inutilement verbeux et que ça les rend seulement 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.

Committo,Ergo:Sum

Committo,Ergo:sum a écrit :

parce que c'est inutilement verbeux

Je ne trouve pas cela juste :

<avant> (...) </avant>
ce n'est pas significativement plus "verbeux" que
<B_nomdelaboucle> (...)

Par contre, je trouve cela "parlant".
Ce n'est pas la même chose. :slight_smile:

JLuc

Attendez la vidéo !!
Elle dure 2h20, on est en train d’essayer de faire quelque chose de propre avec !!
(mais si ça continue, on aura qu’une capture sur 3)

.Gilles

2009/7/1 JLuc <jluc@no-log.org>

Pour rendre un peu plus clair la discussion, ca serait possible de faire une page sur contrib résumant la modification de syntaxe proposée par ESJ ?

Parce que les listes c sympa, mais pour y voir clair, y a pas pire J

Je répète que l'important n'est pas une des solutions possibles que j'ai montrée, et qui a déjà été améliorée grâce à la discussion qui s'en est suivie, que la problématique qu'elle entend résoudre. Balancer une autre syntaxe sans expliquer le pourquoi (les pbs à résoudre) et le comment (les outils de migration que j'ai mis au point avant de proposer une telle démarche), ne peut que provoquer le rejet.

Committo,Ergo:Sum

Samy Rabih a écrit :

Parce que les listes c sympa, mais pour y voir clair, y a pas pire J

Si, les listes ou les gens écrivent en HTML.

BoOz