Oui, c’est tolérable, et potentiellement intéresant pour certaines utilisations mais est-ce indispensable ?
Alors pour mon premier exemple : j’ai volontairement raccourci le contenu de la div à #TITRE pour clarifier l’exposé, mais dans le cas réel qui me concernait, il y avait une quinzaine de lignes de code, dont une boucle qui rendait ta solution impossible (pour info, mon est en display:block).
On retombe alors dans le travers classique de la conformité xml : devoir recopier du code en double (ou plus) pour les parties alternatives des conditions.
Ce simple problème démontre qu’on peut tomber dans des cas où la validation du squelette oblige à des contorsions sans gain.
Je pense, avec encore une fois les longues heures de XSLT que j’ai dues subir en tête, que dans le cas moyen la complication du code dépasse le gain qu’on a en prévisibilité : la facilité accrue de maintenance du code n’est alors qu’illusoire car sa taille augmente rapidement du fait de la verbosité inévitable de toute syntaxe conforme xml (ce que tu ne cesses d’ailleurs de répéter).
Quant à mon deuxième exemple, qui écrit de telles horreurs ? Moi ! 
Le problème :
- J’ai trois boucles successives que l’on ne peut pas résumer en une seule.
- Le résultat de ces trois boucles doit s’afficher dans un div unique
- Le div en question ne doit être ouvert que si l’une des trois boucles renvoie du contenu
- Le tout en étant optimal par rapport à la base de données : pas de requête supplémentaire
=> j’ai choisi en toute connaissance de cause d’utiliser un bon vieux flag, ça a l’avantage d’être clair et économique en ressources. Là encore c’est un cas typique où j’ai choisi de sacrifier la beauté mathématique de mon code à son efficacité, ce que, à mon avis, un langage de template web devrait toujours faire : on n’est pas en train de construire des IA auto-adaptatives, on produit des sites internet, un haut niveau de formalisme n’est donc pas forcément nécessaire.
- A la question de fond:
est-il vraiment nécessaire de distinguer le passage du monde spip au monde du langage produit
tu réponds « non », mais tu déplores le pb des espaces et lignes vides dans le code produit par SPIP,
qui découle directement de cette indistinction. Tu penses le résoudre par une 2e passe sur le résultat, avec une analyse non triviale (« sauf bien sur pour Pre » dis-tu), c’est-dire fondée sur une DTD (mais tu as dit que tu ne voulais pas la donner) et une connaissance de la sémantique associée. Tu vois le prix que tu payes à refuser de répondre « oui ».
J’applique la règle des 80% de gain pour 20% d’emmerdement qu’on m’a citée ici
Je constate que dans la quasi-totalité des cas, les espaces laissés par spip après le passage du compilateur sont non signifiants => je propose donc qu’on les supprime systématiquement en post-processing par un simple jeu de règle :
- substitution de ([\t ]+\n[\t ]+)+ par \n
- substitution de [\t ]+ par " "
On laisse ensuite les outils au développeur de squelette pour désactiver ce filtre pour tout un squelette par la simple présence d’une balise du type #laisser_espaces, ou encore potentiellement par un #strict{ } (plus difficile à coder au niveau du compilo, certes).
Pour info, j’ai essayé de développer un filtre appelé par #FILTRE pour ça, mais je n’ai pas réussi. Je ne sais pas d’où vient le bug, mais le filtre n’est apparemment pas appelé au bon moment pour produire l’effet escompté. Bon, en même temps j’ai pas cherché trois jours…
Je cite le cas de
car il est facile de mettre en œuvre une exception pour cette balise qui est présente dans la dtd de 95+% des données produites par les squelettes spip.
Encore une fois, je raisonne en terme d’optimisation possible pour simplifier la vie de l’utilisateur (ici le webmestre qui pond ses squelettes) tout en produisant un résultat le plus propre possible. De toute manière, si l’utilisateur fait des efforts, il produit du code xhtml qui sera indenté par sax et n’aura que très peu besoin de ce filtre (uniquement dans les feuilles de l’arbre xml de la page produite), alors à quoi bon lui imposer une discipline de fer pour un résultat finalement peu éloigné de ce qu’il peut avoir simplement ?
Au passage, une idée vient subitement de me traverser l’esprit : suivant comment le compilateur est construit, la compression des \s peut aussi se faire pendant la compilation du code.
Pendant la phase de repérage des marqueurs spécifiques des boucles, le compilateur peut décider de supprimer tous les caractères non signifiants précédant et suivant immédiatement un marqueur de boucle reconnu
=> disparition du problème puisque les boucles imbriquées verront les \s de séparation ignorés à la compilation.
C’est même plus propre que le post-processing, et ça ne nécessite pas la séparation formelle des deux mondes dans le source.
Alors je ne connais pas exactement les entrailles du compilo de spip, et mes cours de compilation remontent à quelques temps, mais vu ce dont je me souviens des processus d’analyse lexicale, ça doit être faisable, non ?
- L’argument qu’il suffit de qq RegExp pour faire colorer comme il faut les squelettes SPIP par n’importe quel éditeur est faux, et en théorie (les RegExp ne peuvent pas analyser les structures parenthétiques de profondeur quelconque) et en pratique (depuis 8 ans que SPIP existe, on a eu là-dessus que des solutions rares et incomplètes). Je suis plutôt d’accord avec toi que la notation <? ... ?> est « moche », et qu’effectivement on en vient facilement à les écrire systématiquement en début de ligne pour s’y retrouver. Mais la question de fond est la suivante: quand on mélange 2 langages voire plus (un pré-processeur, que ce soit SPIP, PHP ou autres, et un langage conforme XML plus éventuellement son langage de script et ses styles CSS), peut-on espérer une syntaxe « belle » ? Adopter la solution syntaxique de XML a au moins l’avantage de pouvoir profiter des outils qui essayent que la réponse soit « oui », alors que cet amalgame est un handicap initial énorme.
Je parlais de coloration possible facilement dans le cadre de la proposition de langage « xml ou presque » que je propose, pas avec la structure actuelle des boucles.
I.e. : la syntaxe de boucles que je propose étant conforme xml, elle est déjà correctement colorée par les analyseurs.
Il ne reste plus alors qu’à rajouter quelques règles pour colorer les et autres mots clés propres à spip (il y en a finalement très peu) d’une autre couleur pour les faire ressortir, de même pour les #\w+
Ce n’est pas une coloration complète au sens mathématique, mais elle suffirait à mon avis amplement à faciliter la vie des développeurs de squelettes.
Parfois, le mieux est simplement l’ennemi du bien…
- D’accord pour souhaiter une
Normalisation des différents parenthésages
mais tu juges bien vite ce qui reste pour moi un exemple parmi d’autres possibles. Dans la grande majorité des langages de programmation, les accolades délimitent des blocs d’instructions, je trouve donc assez normal que les boucles de SPIP soient délimitées par elles (on peut toujours ajouter en commentaire après « } » le nom de la boucle fermée, voire obliger à le faire). Si on veut absolument que les accolades n’aient qu’une seule signification, c’est plutôt leur utilisation dans les criteres et les listes d’arguments des filtres qu’on devrait les remettre en question, l’usage étant plutôt d’employer des parenthèses. Mais cet impératif de signification unique d’un caractère me semble une contrainte apportant plus d’inconvénients que d’avantages
Pour ma part, je suis très attaché à la signification unique du signe de parenthésage : ça évite des confusions.
Par contre j’avais conservé les accolades dans ma proposition par souci « historique », mais tu as raison, je pense qu’à changer autant le langage en profondeur, il vaut mieux utiliser les parenthèses pour passer les paramètres et rentrer dans la norme que le plus grand nombre connait (et ça a l’avantage d’être plus facile à taper en azerty :).
Du coup, faudrait permuter les parenthèses et les accolades dans ma proposition, je le ferai le jour où je la mettrai sur le wiki.
- L’idee de se rabattre sur PHP n’est pas recevable, parce que ça effrairait d’avance les non programmeurs, et que c’est un des langages les plus mal conçus qui soit. Tu dis toi-même qu’il est déplorable qu’on puisse y écrire des choses comme:
<<?php echo 'i>'; ?>
pour produire une balise « », le rôle d’un langage de « templates » en général est justement de ne pas donner toute la puissance d’un langage de programmation, pour éviter de partir sur des fausses pistes et fournir un aide à la mise au point plus précise que les outils de debug std du programmeur.
C’était une proposition alternative à peine esquissée, je n’y ai pas encore trop réfléchi.
L’idée m’est venue car je trouve parfois que ta proposition part tellement dans cette direction qu’il vaudrait mieux carrément sauter le pas en fournissant une boîte à outil réduite, bien conçue et parfaitement documentée pour les débutants, tout en permettant de fait aux codeurs confirmés d’utiliser directement leurs compétences en php.
Je trouve qu’elle est recevable dans ce cadre, et le fait que php permette des horreurs n’est pas vraiment un argument pour le coup : il est déjà utilisable directement dans les squelettes et le restera dans tous les cas, donc quelqu’un qui veut faire du moche avec le fera.
Et cette proposition n’est incompatible avec aucune syntaxe, elle peut très bien exister en plus de la tienne, ou même l’actuelle, puisque le code php est évalué par spip.
- Demander à des utilisateurs de changer de syntaxe n’a de chance de succès que si cela leur amène des fonctionnalités supplémentaires, sinon ils refuseront d’entrée, et avec raison. Je ne discuterai donc pas plus ta proposition alternative que je ne l’ai fait sur le Wiki, parce je pense que, beaucoup plus que la mienne, elle:
serait une erreur car on y perdrait finalement beaucoup en souplesse au profit d’une beauté mathématique purement formelle.
Dire que la syntaxe que je propose n’amène pas de nouvelle fonctionnalité est faux :
- la syntaxe des boucles est conforme xml donc colorable
- elle est aussi simplifiée : nom de boucle facultatif, nouvelle syntaxe des et
- le balisage est simplifié par la suppression des [()] dans la majorité des cas où ils sont utilisés aujourd’hui
- les filtres permettent de faire des choses qu’ils ne permettaient pas avant
- la gestion des inclusions est simplifiée et automatisée
- les blocs multi n’utilisent plus qu’un seul concept => plus facile à expliquer aux contributeurs
- les chaînes de traduction passent dans le monde des balises où elles devraient être => clarté et utilisation de filtres facilitée
De plus je ne suis absolument pas à la recherche de beauté mathématique, mais justement des seules fonctionnalités (peu nombreuses !) qui me manquent au quotidien dans le développement de squelette le plus terre à terre qui soit.
- Tout à fait d’accord en revanche avec ta remarque,
si nouvelle syntaxe il doit y avoir, celle-ci doit pouvoir permettre à un idéaliste motivé de pondre du code conforme (ce qui est aujourd’hui impossible avec la syntaxe actuelle des boucles), cependant ça ne doit en aucun cas être une obligation pour que le squelette s’exécute
et je rappelle que le compilateur est prévu depuis le début pour accepter plusieurs syntaxes, autrement dit que cette nouvelle syntaxe ne serait de toutes façons pas imposée, juste proposée.
idem
A bientôt
Simon
