balises #EXTENDS et #BLOCK

Une idée que je n’ai pas encore cherché à implémenter, mais voilà :

Si dans SPIP5.0 (ou à partir de 5.1, si ça prend du temps à mettre en place), il était ajouté 2 balises pour proposer une alternative aux <INCLUDE...> et #INCLUDE, il deviendrait possible « d’inverser » le système de pages appelantes :

aujourd’hui et toujours possible :

cf spip/dist etc.

Pour appeler le sommaire, il faut faire spip.php?page=sommaire, pour appeler le plan du site, il faut faire spip.php?page=plan, ce qui nécessite la présence des fichiers sommaire.html et plan.html

Chacun de ces 2 fichiers ont besoin du boilerplate html pour produire une page html complète (et valide).

<doctype ...
<html>
    <head>
        ...
    </head>
    <body>
        ...
    </body>
</html>

avec les 2 nouvelles balises :

(très, très synthétique)

ici, le boilerplate du desgin d’un site serait dans un fichier base.html :

[(#REM) templates/base.html]
<html>
...
<body>
    ...
    [(#BLOCK{main,env})]
    ...
</body>
...
</html>

l’appel de spip.php?page=plan irait chercher le fichier plan.html qui irait lui-même chercher la base.html

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

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

idem pour spip.php?page=sommaire :

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

[
    (#BLOCK{main})
    <BOUCLE_articles(ARTICLES) {!par date} {pagination}>
        ...
    </BOUCLE_articles>
]
3 « J'aime »

Intéressant.

C’est un nouveau paradigme pour le « templating ».

En première impression, me vient un détail (futile ?) qui tient à une limitation de l’AST : à savoir qu’on ne peut pas insérer une BOUCLE dans la partie conditionnelle d’une BALISE, à savoir entre ) et ], enfin si je ne m’abuse.

Tu sembles dire que c’est possible en intervenant sous le capot pour les balises hypothétiques #BLOCK et #EXTENDS ?

1 « J'aime »

Tu connais zcore ?

C’est possible @placido depuis SPIP 4.0 SPIP 4.0 - SPIP

1 « J'aime »

De memoire c’est possible à partir de la 4.0

Effectivement il me semble que zcore répond en partie au problème auquel le mécanisme proposé par @JamesRezo. Mais la mécanique proposé par james peut je pense s’appliquer à d’autres cas que du templating large, me semble-il. Je pense par exemple a certaines probématiques que j’ai avec saisies et ses vues, notamment en terme de cache statiques. Peut être que cela répondrait à ces problèmes (mais à confirmer, faudrait que je me pose bien au calme pour reprendre ce dossier).

Question subsidirais à @JamesRezo

  • qu’en est-il de la notion d’environnement
  • qu’en est-il de la possibilité de faire « remonter » les doublons.

Ce n’est pas le même paradigme non plus que zcore : la proposition là est dans le même ordre que ce que proposent d’autres système de templating en général (comme Twig ou Blade), ce qui permet notamment d’un point de vue du fonctionnement interne d’utiliser des extends en PHP sur des classes générées.

Côté faisabilité, c’est certainement pas évident avec le code interne généré actuel de SPIP cependant.

1 « J'aime »

Mazette ! On n’arrête pas le progrès !

1 « J'aime »

Elle resterait là même a priori ?

Bonne question, je ne sais pas :slight_smile:
Mais je la note :wink:

Précisons ce point.

Le mécanisme {doublons} permet de ne pas afficher deux fois le meme objet s’il est appelé dans 2 boucles différentes. {doublons} - SPIP.

D’un point de vue technique je crois, de memoire, que ca stocke en globales (bouh) des id_xx.

Il est possible pour un squelette appelant de dire au squelette appelée « tiens compte du doublonnage » (via <INCLURE{doublons}> <INCLURE> d'autres squelettes - SPIP)

Mais par contre, tout du moins pour une inclusion dynamique (sans doute aussi pour statiques), l’emploi de doublons dans le squelette inclus n’a aucune conséquence sur l’interprétation du squelette appelant).

Cf cette vielle dicussion

Et une demande récente

1 « J'aime »

Merci @maieul

OK, faudra tenir compte de ça :wink:

Autre point à tenir en compte : le cache, et le moment où le squelette reéférencé par #EXTENDS est interprété.

1 « J'aime »

Mais la mécanique proposé par james peut je pense s’appliquer à d’autres cas

Ce n’est pas le même paradigme non plus que zcore

Je ne dis pas le contraire :slight_smile:
Je demandais juste à @JamesRezo s’il connaissait.

Et effectivement ce n’est pas la même approche, zcore est « vertical » (php → squelettes), en passant par styliser, alors que l’approche par balise est « horizontale » (squelettes <-> squelettes).

C’est possible @placido depuis SPIP 4.0

Mais avec un #INCLURE bien sûr, pas un <INCLURE>.

Dans l’absolu, si on sait faire « remonter » des doublons au squelette incluant, ou saurait faire remonter n’importe quoi non ?

@marcimat c’est pas le même paradigme du moins de vue de l’implémentation, certes, mais concrètement pour le public du système (qui sont là les intégrateurices) ça permet de résoudre quoi en plus quand on utilise déjà zcore au quotidien ? Je n’ai jamais trop eu de blocage majeur ou sinon souvent contournable, donc je cherche à comprendre ce que ça permet d’autre/de mieux.

1 « J'aime »

@placido ne parlait pas des inclure je crois, les boucles peuvent s’écrire dans la partie conditionnelles de n’importe quelle balise maintenant à priori

Ça semble intéressant cette idée.

Donc dans squelettes/sommaire.html il pourrait y avoir plusieurs blocs, un #BLOCK{main}, un #BLOCK{aside} etc ?

Dans ce cas ce ne serait plus le squelette du sommaire, mais le fichier des squelettes du sommaire, donc peut être le nommer blocks_sommaire.html ou blocks/sommaire.html ?

Sinon, question terminologie, ce que tu appelles des blocks, pour moi ça s’appellerait plus des slots.
C’est un terme et une balise (<slot>) utilisé dans les webcomponents par exemple, pour désigner des zones « remplissables » du DOM d’un composant.
Mais en français, je ne vois pas pour l’instant (slot = fente, rainure, logement…)

En tout cas ça m’arrangerait bien que ce ne soient pas des blocks parce que c’est un terme et un objet que j’utilise dans un plugin éponyme :slight_smile:
(Mais peut être il faudrait que je change le nom ? c’est un des points de ma todolist)

Même avec zcore, pour ma part, je ressens parfois la carence de cette notion d’héritage dans le « templating ».

(Je sais bien que c’est le rôle dévolu à #COMPOSITIONS ) Mais ce dernier est un outil de gestion pour les webmestres, tandis que je voudrais un outil qui opère vraiment sous le capot, sans besoin d’éditer xml et autres.

Un exemple qui parlera peut-être : lorsque l’on souhaite un « template » plus simple commun à à toute une série de pages à vocation annexes (inscription.html, login.html, spip_pass.html, oubli.html, 404.html) ; et bien j’en suis réduit à faire une variante lègère du body body-simple.html (avec un seul zbloc à l’intérieur), puis des liens relatifs dans le même dossier pour chaque cas cité (body-login.htmlbody-simple.html,…).

C’est un pis-aller qui a le mérite de fonctionner, mais je serai intéressé par une approche un peu plus recommandée.

1 « J'aime »

Oui, j’en avais entendu parlé, mais à vrai dire, j’avais oublié. J’ai été briefé rapidement tout à l’heure,en privé, j’ai bien noté ça, pas de soucis.

Ce n’est pas moi qui appelle ça comme ça :slight_smile:
ça vient de jinja à l’origine, comme l’a dit @marcimat , ça a insipiré blade chez laravel, twig, mustache

Dans blade, les slots servent à autre chose

Ce serait dommage de trouver un terme original (trop ?) au point de perdre des personnes qui viendraient d’ailleurs …

Oui. aside, head, footer, breves, messages, agenda, mots-cle, register, Willkommen, ce qu’on voudrait, a priori …

L’idée ici, c’est que le terme main (ou autre) dans les accolades de la balise #BLOCK, c’est un identifiant de « bloc », et ne correspond pas à un fichier. Dans l’AST, quand SPIP « compile » un fichier squelette, il référencerait les « blocks » du fichier appelé, par leurs identifiants, et regarderait ce que ce fichier EXTENDS. Pour produire un « rendu final », une « réponse », il (SPIP ou l’AST, …) n’aurait qu’à injecter dans le fichier de base (pour poursuivre avec l’exemple plus haut) le résultat des autres compilations …

Je t’accorde que c’est pas facile à appréhender, vu que par texte, c’est pas (pour moi), facile à décrire :wink:

Fort intéressant tout ça.

#EXTENDS j’ai pigé, mais sur #BLOCK j’ai un doute : #BLOCK{main} signifierait qu’on inclut le squelette main.html c’est ça ? Alternative à #INCLURE / <INCLUDE> ?

Sur la comparaison avec zcore -et sous réserve d’avoir bien tout compris- je vois 2 avantages : d’une part ça permet de tout gérer directement dans les squelettes, sans besoin de déclarer séparément des choses en php.

Et d’autre part dans ce fonctionnement on n’est plus limité à une seule déclaration de blocs principaux valables pour tout le site, pour les pages avec des layouts très différents c’est plus souple.

Si jamais ça débouche sur une branche expérimentale, je serais très intéressé pour tester.

1 « J'aime »