balises #EXTENDS et #BLOCK

Non. ici, main n’est pas un fichier.

J’essaie autrement :

soit base.html =

[(#REM) templates/base.html]
<doctype ... >
<html>
...
<body>
    ...
    [<div class="titre">(#BLOCK{title})</div>]
    ...
    [<div class="content">(#BLOCK{content})</div>]
    ...
</body>
...
</html>

Quand un utilisateur fait une requête spip.php?page=plan&param=1&var_truc=untruc, SPIP irait chercher « classiquement » le fichier plan.html =

[(#REM) squelettes/plan.html]
#EXTENDS{base}

[ (#BLOCK{title})
    <h1><:plan_du_site:></h1>
]

[ (#BLOCK{content})
    <BOUCLE_secteurs(RUBRIQUES) {racine} {par num titre}{!par date}>
        ...
    </BOUCLE_secteurs>
]

Dans ce fichier, le compilo SPIP, trouverait qu’il EXTENDS le fichier base.html qui dit : à cet endroit, je mettrai le contenu d’un bloc qui s’appelle title et là, le contenu d’un bloc qui s’appelle content (sinon, je mets rien, ou … ça se discute, …)

À la suite de ça, le compilo SPIP trouverait dans plan.html qu’il y a un [(#BLOCK{title}) un titre] et un [(#BLOCK{content}) un contenu]

À la fin, caches générés et tout et tout, la page finale serait la base, avec son bloc title remplacé (inclus?) par celui de plan.html (donc, un titre) et son bloc content remplacé par celui de plan.html, (donc, un contenu) …

En tout, pour cet exemple : 2 fichiers (base.html et plan.html)

Je vais avoir besoin de l’aide d’un·e pédagogue ^^

Oui oui, ça j’ai bien compris.
Ils pourraient même avoir une base (#EXTENDS) variable ou conditionnelle, si on veut jouer.

Tout ce qui concerne les squelettes étant en français, il me semblerait logique de continuer dans cette voie.

Pour le fonctionnement moi je pense avoir compris, c’est du remplacement de morceaux, et un même unique squelette peut alors fournir plusieurs « morceaux » différents dans le même fichier qui ne seront pas spécialement affichés tels quels à la suite (c’est bizarre comme concept faut s’habituer), mais plutôt déplacer dans des « emplacements » ailleurs.

Comme @tcharlss ce qui m’intéresse dès le début de la description, c’est bien de pouvoir prévoir plus facilement plusieurs dispositions (layouts) différents dans le même site, alors que z-core en force un unique par défaut partout (et quand on personnalise c’est toujours exactement avec la même liste de zones possibles). En revanche je trouve ça bien de pouvoir les listes/manipuler en PHP aussi, car le but (pour moi) c’est possiblement à terme de permettre plusieurs dispositions déclarables explicitement dans le même site et donc pouvoir les lister et les assigner à des pages (tout comme on peut assigner des compositions, mais que pour les layouts précisément). J’avais commencé un plugin Dispositions mais c’est resté un POC jamais fini et je bloquais dans « styliser » sur des paradoxes complexes (je sais plus de tête).

De ce que j’ai compris dans l’appel d’origine (dans base ou autre fichier quelconque), on peut possiblement dire quel est le contenu par défaut aussi (quand pas surchargé). Un peu comme le « dist.html » pour Zcore.

Par contre pour le nom je rejoins @nicod le mot « block » est utilisé dans presque tous les CMS pour désigner des « morceaux de contenu configurables, avec une liste de paramètres, qu’on imbrique comme des Lego » (j’avais commencé un plugin Block aussi en tant que refonte du noizetier mais différemment mais jamais fini non plus…). Après peut-être qu’il peut y avoir une notion pour le langage de template et une notion pour l’admin, qui sont différentes sans se gêner ? Mais c’est quand même mieux si ya d’autres termes quand même.

Par exemple « parts » (morceaux), « emplacements » (qui est la meilleure trad de « slots » je crois sans faire du mot pour mot non ?), « zones » (qui a l’avantage d’être multilingue au moins FR + EN à la fois)

Dans mon début de plugin Dispositions, j’avais utilisé ces deux concepts :

  • zones : morceaux/emplacements de pages finales qu’on sont personnalisables => remplace justement les BLOCS de « zcore », qui ne sont PAS des blocs au sens de tous les autres CMS
  • dispositions : description globale d’un layout avec un nom humain, une liste de zones utilisées dedans, quelle zone est la « principale », quels zones génèrent des 404 si vides (reprise du concept de zcore)

Je pense donc toujours que « zones » est le meilleur mot pour l’instant :slight_smile: #ZONE pour la balise, zone en PHP yaml etc

#EDIT, #GET, #SET, #ARRAY, {ajax}, {critère LIKE valeur}, {where id_rubrique=10 OR id_rubrique=20}, #ID_THREAD, #LOGIN_xxx, #NULL , #PIPELINE, #PLUGIN, #SELF, |afficher_tags, |charset2unicode, |is_null, |match, |picker_selected, |PtoBR, |wrap

Et j’ai pas tout mis … :slight_smile:

Non mais là tu mélanges des items purement Mysql ou PHP, ça n’a rien à voir.

Base toi plutôt sur Glossaire - SPIP

Ce sont des balises, filtres, critères qu’on utilise dans des fichiers squelettes …

En repensant à Twig Twig for Template Designers - Documentation - Twig PHP , il faut aussi gérer ou non l’affichage du contenu présent dans le bloc du template hérité, ce que fait twig avec {{ parent() }} : autrement dit, un bloc soit remplace le contenu déjà présent, soit le complète (en haut et / ou en bas)

1 « J'aime »

C’est ce que j’ai fait

En tout cas, en terme de syntaxe je verrais plus un truc ouvrant/fermant, comme les boucles :

<BLOC(content)>
...
</BLOC>

qui serait le pendant de la syntaxe de Jinja et Twig (que j’ai pratiqué) :

{% block content %}
...
{% endblock %}

Plutôt qu’une syntaxe en balise avec crochet et parenthèses

[(#BLOC{content})
...
]

C’est lourd, moins lisible, source d’erreurs.

1 « J'aime »

Et puis une déclaration PHP d’une surcharge, ça se fait. Si balise_EXTENDS_dist($p) existe dans SPIP, tu peux faire un plugin synntaxespipenfrancais qui ferait :

function balise_ETENDRE_dist($p) {
    return balise_EXTENDS_dist($p);
}

on a ça dans SPIP pour <INCLUDE et <INCLURE

<BLOCK(content)>
...
</BLOCK>

J’aime bien aussi.

Et pourquoi pas plus tard, un parser (phraseur chez nous) qui comprendrait une syntaxe spip en allemand ou en castillan, …)

En revoyant la doc de Twig, il y a aussi toute la partie escaping qui me revient, ça c’est vachement bien foutu, avec un mode automatique très sécurisant.
Moi je suis obligé de gérer ça moi même sur tout ce qui est contribué et affiché côté public.

ESJ en avait parlé à Avignon en 2009 : Syntaxes Alternatives pour SPIP (vidéo ici : Des squelettes XML lisibles, c’est possible et c’est pour « bientôt », par ESJ - Médias [@spip.net] et gros article : Des squelettes SPIP en XML, est-ce possible ? - La Taverne à Tonton)

Tu vouliez dire :stuck_out_tongue:

<ZONE(content)>Pas content</ZONE>

Moi c’est pas tant FR/EN le problème, que vraiment ne pas utiliser le vocabulaire connu dans les autres CMS n’ayant rien à voir. Et en fait je pense pas qu’on puisse utiliser les mêmes termes sans se gêner car forcément c’est lié et il va falloir le documenter (en article et dans les labels dans l’admin).

Très concrètement, on peut pas du tout dire aux gens : vous placez vos blocks (squelettes configurables Lego) dans des blocks (zones remplaçables des pages complètes) !

Actuellement nous les blocs s’appellent « noizettes » ce qui est encore pire, private joke incompréhensible pour personne etc. Donc à terme, comme dans vraiment tous les CMS, ça devra s’appeler « les blocs » afin justement d’utiliser le même vocabulaire que partout ailleurs. Et je pense que les utilisateurs finaux de l’admin (ceux qui écrivent, personnalisent le contenu etc) sont bien évidemment plus nombreux que les utilisateurs « intégrateurices » qui vont modifier les templates. C’est deux types de publics visés, mais l’un est immensément plus nombreux que l’autre (c’est logique, pour un site, ya 1 ou 2 devs ou 0 si ça utilise que des plugins génériques, et par contre ya plein de gens dans l’admin, toujours plus que les devs).

En conséquence ça me parait donc bien plus important que dans l’admin (et doc d’utilisation des plugins) on puisse utiliser des termes utilisés ailleurs (blocs/blocks pour les Lego), et moins important que les devs moins nombreux n’aient pas le même terme que dans Twig. Tout en ayant un terme compréhensible comme « zone » (ou autre hein mais celui là est le même en FR et EN donc ça résout l’autre problème).

Ah non ya aussi « region » ! (vu ailleurs, dans Drupal ou autre je sais plus)

<REGION(content)>Pas content</REGION>

je suis assez d’accord avec l’analyse de @rastapopoulos a part sur REGION qui risque une confusion avec les divisions administratives francaises

Quand je dis « je suis assez d’accord » ca veut dire que je pense qu’il est juste de se poser la question d’une éventuelle confusion sur le sens de « Bloc » entre les 2 niveaux (templating vs editorial).

Mais pour autant est-ce que ce risque est réel ? Est-ce qu’on peut pas être assez intelligent·es pour expliquer la différence ?

1 « J'aime »

Assez d’accord aussi, ça donnerait un degré de liberté, ça nous permettrait de ne pas se forcer (ou être forcés à) calquer la fonctionnalité iso (i.e. à 100% identique), même si on la reproduit à 90%, avec l’idée de parent() citée par @marcimat.
Il peut toujours y avoir des spécificités liées à SPIP, du coup peut être on arriverait à 125% ? :smile:

Je rappelle que SPIP comprend déjà à la fois <INCLUDE> et <INCLURE> nativement (et sans plugin « syntaxe_fr » ou « syntaxe_en ») alors il pourrait bien comprendre à la fois <BLOC> et <BLOCK>, ainsi que <EXTENDS> et <ETENDRE>.

Au passage (et comme on aime les statistiques sur ces listes) on peut compter les occurrence de ces 2 syntagmes sur les repos spip, galaxie, extensions, themes et squelettes :

  • Occurrences de <INCLURE> : 19323
  • Occurrences de <INCLUDE> : 39

On peut tirer des leçons de ce constat. Par exemple « quasi personne veut causer anglais » et « ça sert à rien de faire semblant, on change pas son ADN comme ça ! ».
Mais ya d’autres leçons certainement, très différentes, et les questions que ça pose aussi, genre (« Et comment on fait alors, pour s’immerger incognito dans l’Écosystème PHP ? »), et c’est un autre sujet, un autre thread peut être.

Sur le fond, c’est sympa cette liberté gagnée.

Mais dans plein de cas, il faudra un même bloc à insérer dans différents modèles de pages (par exemple un bas de page), et dans ce cas il faudra faire une inclusion, pour ne pas répéter le même bout de code, n’est il pas ? Ça donnera

<BLOC(basdepage)><INCLURE{fond=bloc/basdepage,env}></BLOC>

On aura dans ces cas les mêmes fichiers squelettes qu’avez ZCore, mais, semble t il présentement, avec un niveau d’abstraction et de complexité supplémentaire pour les joindre.

Ou alors il faut décrire quelque part (où ça ? dans le template/base ?) une version « par défaut » de ces blocs ? comme le extra/dist.html de ZCore, qui décrit l’extra utilisé par défaut, lorsqu’il n’existe pas extra/ploc.html pour la page ploc.

Mais alors il n’y en aura qu’une version par défaut, tout comme dans ZCore ? J’avoue que ça ne m’a pas souvent gêné. Ou alors il faut enrichir le mécanisme décrit pour définir plusieurs versions « de base » des blocs, communes à plusieurs pages ? La suite présente 2 pistes.

Sur la syntaxe je préfère <BLOC(extra)>truc</BLOC> à [(#BLOC{extra}) truc].

Mais tant qu’à s’inspirer de l’existant, il ya avec les boucles une plus grande richesse à disposition, du moins pour cette histoire de versions par défaut plurielles.

Dans leur expression la plus basique, les boucles sont comme ça :
<BOUCLE_nomdelaboucle(TABLE){args}>
La syntaxe prévoit prévoit

  • un argument privilégié (la ou les tables), et c’est ce qui est utilisé dans la syntaxe <BLOC(basedepage)>
  • un nom de la boucle. La syntaxe du nomdelaboucle pourrait par exemple servir pour définir la ou les version-s « par défaut » dont le besoin a été signifié plus haut : <BLOCK_dist(basdepage)> par défaut ou <BLOCK_speciale(basdepage)> pour les 3 squelettes de pages spéciales.

Inversement, au lieu de l’argument privilégié, on pourrait utiliser ce nom pour indiquer le nom du bloc. Ça donnerait : <BLOCK_basdepage> (qui serait très apprécié des IDE). Et dans ce cas si le besoin d’une ou de plusieurs versions par défaut est avéré, ce serait le nom de cette variante qui irait comme argument privilégié : <BLOCK_basdepage(dist)>, <BLOCK_basdepage(speciale)>

Non, j’imagine que la page squelette principale, ou appelante, aurait un contenu par défaut :

<BLOC(basdepage)>
Contenu par défaut ou <INCLURE{fond=truc}> ou ce que tu veux.
</BLOC>

Le bloc appelé pouvant alors, comme dit @marcimat remplacer le contenu par défaut, ou bien s’insérer avant, ou après.
Cf la doc de Twig citée : Twig for Template Designers - Documentation - Twig PHP

Du coup, si tu ne déclares par de <BLOC(basdepage)> dans le squelette ma_page.html, c’est le contenu par défaut qui s’affiche.

Je ne me souviens plus exactement mais je crois que c’est comme ça que Twig fonctionne.