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 
Mais je la note 
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 »
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
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).
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
(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.html → body-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
ç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
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 »
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¶m=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 #ZONE pour la balise, zone en PHP yaml etc