Bonjour,
Je viens de tomber sur cette syntaxe qui a pas mal de points communs avec celle de SPIP, les <> en moins.
Du coup, elle n'est pas détruite par nVu ou BlueGriffon.
Est-ce que c'est une piste intéressante ?
-- RealET
Mais encore ?
* RastaPopoulos tapuscrivait, le 17/03/2011 09:13:
Bonjour,
Je viens de tomber sur cette syntaxe qui a pas mal de points communs
avec celle de SPIP, les <> en moins.
Du coup, elle n'est pas détruite par nVu ou BlueGriffon.Est-ce que c'est une piste intéressante ?
Mais encore ?
Aujourd'hui, on est obligé de dire à quelqu'un qui veut découvrir SPIP qu'il ne doit utiliser ni nVu, ni Kompozer, ni BlueGriffon qui détruisent le code source des squelettes.
Ça veut dire qu'il n'y a pas d'éditeur WYSIWYG Open Source de squelettes SPIP.
Ce qui m'avait séduit dans la proposition d'ESJ à Avignon, c'était :
- le code non détruit par par ces éditeurs
- la possibilité de faire une boucle dans la partie conditionnelle d'une balise (parce que faire des inclure juste pour ça, c'est lourd)
Donc, à défaut de la syntaxe proposée par ESJ à Avignon, est-ce qu'une syntaxe inspirée de Creating and Using Templates (Symfony 2.x Docs) pourrait répondre à ces 2 problématiques, sans introduire la lourdeur reprochée à la syntaxe XML d'ESJ.
-- RealET
* RastaPopoulos tapuscrivait, le 17/03/2011 09:13:
Cette syntaxe n'alourdit pas les squelettes std si on n'oublie pas les abréviations qui vont avec,
j'avais montré des statistiques à ce propos sur les milliers de squelettes de la zone.
La vraie question est de savoir si la communauté est prête à renoncer à ses habitudes
(que j'estime mauvaises) pour pouvoir profiter, comme tu le dis, des éditeurs XML et autres outils XML. La syntaxe que tu signales butera sur le même problème, et il y a quantité de détails techniques à prendre en compte qui constituent un travail que je pense absurde de refaire pour cette variante qui ne présente aucun avantage supplémentaire à ce que j'ai proposé.
Committo,Ergo:Sum
Bonsoir,
si je prends un exemple de cette syntaxe :
<ul>
{% for user in users %}
<li>{{ user.username }}</li>
{% else %}
<li>No users found</li>
{% endfor %}
</ul>
je trouve que l'on retombe sur le problème des langages de
programmations, c'est à dire qu'il y a plein de petits mots partout,
qui compliquent la syntaxe/l'approche.
Le même code en Spip "traditionnel" donne :
<ul>
<BOUCLE_lesAuteurs(AUTEURS)>
<li>#NOM</li>
</BOUCLE_lesAuteurs>
<li>No users found</li>
<//B_lesAuteurs>
</ul>
Sincèrement, je préfère cette syntaxe, surtout qu'elle me permet
aussi d'éviter l'affiche des balises ul, si je veux.
Alors certes, cette syntaxe n'est pas XML compliant, mais si l'on
réfléchi à une autre syntaxe, je voudrais que l'on ne perde pas le
charme de la syntaxe Spip.
De plus, la syntaxe Spip se démarque assez bien du php et du html,
ce qui évite les affreux mélanges que l'on voit ailleurs.
En particulier les notations comme en javascript users.nom sont
intéressantes, mais je préfère encore une fois le simple #NOM
De même, le #TITRE qui marche dans beaucoup de contextes...
Les boucles Spip, c'est génial, et c'est ce qui manque à Wordpress.
Wordpress est l'exemple à ne pas suivre (de toute façon c'est fait
que pour créer des blogs, pas plus).
A bientôt
Grégoire
Salut la liste,
2011/3/17 Grégoire <gobmouch@online.fr>
Bonsoir,
si je prends un exemple de cette syntaxe :
{% for user in users %}
- {{ user.username }}
{% else %}- No users found
{% endfor %}je trouve que l’on retombe sur le problème des langages de
programmations, c’est à dire qu’il y a plein de petits mots partout,
qui compliquent la syntaxe/l’approche.
ça c’est parce que les codeurs sont paresseux et qu’à force de taper des lignes de code on a mal aux doigts 
Le même code en Spip « traditionnel » donne :
- #NOM
- No users found
Sincèrement, je préfère cette syntaxe, surtout qu’elle me permet
aussi d’éviter l’affiche des balises ul, si je veux.
Pour l’affichage conditionnel, on utiliser le si-alors-sinon classique, non ?
ça donnerait ceci :
Je rajoute juste qu’en effet Twig semble un moteur de template bien fichu a la base et extensible, pour ce que j’ai pu en lire.
C’est un moteur de templating qui existait déjà et le projet était en sommeil. Il a été repris comme brique logicielle pour intégrer Symphony.
Il y aurait des avantages certains a reprendre un moteur libre existant,
qui plus est partagé avec un autre gros projet, et à l’étendre pour y introduire les concepts propre à SPIP :
- partager la charge de développement/support/maintenance dudit moteur.
- partager au moins une partie de la syntaxe avec d’autres outils
Je n’ai pas conscience de l’ampleur de la tache que cela représente, mais d’un point de vue stratégique global il me semble que ce serait pertinent.
Maintenant cela a plein d’autres implication qu’il faut prendre en ligne de compte, et c’est une voie très différente de celle explorée par Emmanuel autour d’une syntaxe XML-friendly
Cédric
Salut la liste,
…Twig peut s’étendre sans problème : http://www.twig-project.org/doc/advanced.html
Pour finir j’aime beaucoup sur la page d’intro, l’encart suivant :
Why Twig?
Twig templates are meant to be simple and won’t process PHP tags. This is by design: the Twig template system is meant to express presentation, not program logic. The more you use Twig, the more you’ll appreciate and benefit from this distinction. And of course, you’ll be loved by web designers everywhere.
Twig can also do things that PHP can’t, such as true template inheritance (Twig templates compile down to PHP classes that inherit from each other), whitespace control, sandboxing, and the inclusion of custom functions and filters that only affect templates.
On retrouve exactement des concepts similaires dans le langage SPIP, et ça ouvre des pistes (la notion d’héritage et de sandboxing) encore inexplorées…
Oui le sandboxing est quelque chose auquel je pense. Surtout maintenant que Emmanuel a déporté la vérification des filtres utilisés lors de la compilation,
il serait sans doute assez simple de permettre de définir des listes blanches/listes noires de filtre pour sécuriser ce qui est fait dans un squelette.
La notion d’héritage de template est plus discutable. C’est un concept que j’ai regardé pour préparer mon intervention a paris-web sur la notion de framework HTML.
C’est un concept qui vient au départ de python/Django. Il a des intérêts techniques qui peuvent attirer les développeurs,
mais du point de vue de l’utilisation des templates en contexte de production je suis réservé.
En particulier il n’y a pas de notion de transversalité, et la nécessité de rendre surchargeable oblige assez rapidement à créer un template différent par section (c’est une des premières recommandation de la doc de django, de mémoire).
Ce qui fait assez vite retomber dans le travers initial des templates de la dist de SPIP, à savoir une duplication initiale de code identique simplement pour permettre la personnalisation ultérieure.
Cédric
Justement, tant qu'ils gardent la structure d'un blog, pas de soucis.
Dès qu'il faut sortir des sentiers battus, c'est la merde avec
Wordpress, des trucs qui sont hyper simple à réaliser en Spip,
justement parce que dans Spip on a la notion de "contexte" selon les
boucles, et que l'on peut afficher un éléments d'un autre contexte
sans soucis non plus comme avec #nomboucle:TITRE. Rien que ça,
manquant dans Wordpress, oblige à écrire des trucs vraiment tordus.
La syntaxe, c'est une chose, la souplesse, c'est aussi très important.
Dans <BOUCLE_nomboucle(ARTICLES){id_rubrique}> on a tous les
élements qui font la richesse de Spip, pas d'éléments superflu.
Alors certes, c'est pas XML compatible, c'est un problème, mais ne
copions pas les problèmes des autres pour être XML compatible.
Dans une boucle, si on peut éviter les mots "For, in... step" ce
serait super. Bien sur, on a le mot 'boucle' en français dans
l'exemple, mais c'est le seul, il n'y a pas 'dans', qui allourdirait
la syntaxe.
Je suis bien content que l'on discute de nouveau du changement de
syntaxe, et si celle de Spip devenait XML compliant, pourquoi pas 
Bonne journée
Grégoire
2011/3/19 Grégoire <gobmouch@online.fr>
[…]
Les boucles Spip, c’est génial, et c’est ce qui manque à Wordpress.
Wordpress est l’exemple à ne pas suivre (de toute façon c’est fait
que pour créer des blogs, pas plus).C’est un faux argument : de plus en plus de sites qui ne sont pas du blog,
justement, sont faits sous WP.
Il faut vraiment dépasser cet a-priori.[…]
Justement, tant qu’ils gardent la structure d’un blog, pas de soucis.
Dès qu’il faut sortir des sentiers battus, c’est la merde avec
Wordpress, des trucs qui sont hyper simple à réaliser en Spip,
c’est ta perception, je connais plein de spécialistes de WP qui disent exactement l’inverse
justement parce que dans Spip on a la notion de « contexte » selon les
boucles, et que l’on peut afficher un éléments d’un autre contexte
sans soucis non plus comme avec #nomboucle:TITRE. Rien que ça,
manquant dans Wordpress, oblige à écrire des trucs vraiment tordus.
Ici on parle de Twig, pas de WP.
La notion de contexte n’est ni plus ni moins qu’un espace de nommage, qui peut être introduit facilement, si ça n’existe pas déjà, dans Twig.
La syntaxe, c’est une chose, la souplesse, c’est aussi très important.
Dans <BOUCLE_nomboucle(ARTICLES){id_rubrique}> on a tous les
élements qui font la richesse de Spip, pas d’éléments superflu.
Alors certes, c’est pas XML compatible, c’est un problème, mais ne
copions pas les problèmes des autres pour être XML compatible.
L’enjeu est certes de pouvoir utiliser un éditeur qui soit plus « user friendly » qu’un éditeur de texte.
Mais lans le contexte de Twig, le plus important c’est de pouvoir bénéficier de la force d’un langage de templates développé par une communauté qui ne fait que cela.
Actuellement, ceux qui interviennent sur le moteur de SPIP se comptent sur les doigts d’une main. C’est trop peu pour apporter de nouvelles fonctionnalités, à mon avis.
Dans une boucle, si on peut éviter les mots « For, in… step » ce
serait super. Bien sur, on a le mot ‹ boucle › en français dans
l’exemple, mais c’est le seul, il n’y a pas ‹ dans ›, qui allourdirait
la syntaxe.
Tu bloques sur un langage juste par ce qu’il rajoute un terme ?
A vouloir trop limiter la verbosité d’un langage on rend sa compréhension plus compliquée.
Actuellement il y a justement quelque chose qui est très loin d’être intuitif dans SPIP :
<BOUCLE_art(ARTICLES){id_rubrique}{lang}{doublons A}{par !titre}{‹
›}{tout}{titre_mot=‹ mot_clef ›}>
mélange tout plein d’éléments qui n’ont rien à voir les uns avec les autres. Ca peut devenir vite lourd à maintenir et source d’erreur pour le novice…
Est-ce qu’il ne serait pas plus explicite d’avoir quelque chose comme
{%
pour oiseau dans _art::articles
avec id_rubrique et lang
trie par titre inverse
separe par ‹
›
pour tout statut
avec titre_mot=‹ mot_clef ›
unique dans doublons_A
%}
Pour ma part je trouverais cela beaucoup plus simple…
Oui mais pas seulement. Une chose intéressante à atteindre serait de pouvoir garantir qu'un squelette produira une page XHTML valide après utiilsation quelles que soient les données d'entrées.
Pouvoir passer un analyseur XML sur le source d'un squelette sans que ça râle est une étape en ce sens, j'en avais parlé à Avignon, dont je rappelle que l'argumentaire et la vidéo sont disponibles ici:
http://spip21.smellup.net/spip.php?article17
Pour moi c'est l'argument déterminant pour choisir la cadre syntaxique fournit par XML plutôt qu'un autre, tous les arguments type "facilité" "lisibilité" etc ne faisant que traduire les habitudes culturelles de l'émetteur de l'argument.
Committo,Ergo:Sum