Le 23 février 2014 18:25, Bruno <dsls(a)morefnu.org> a écrit :
>
> Après avoir lu et relu le billet de Bruno sur le blog DC, j'avance dans
la
> refonte des templates de currywurst pour y coller le système d'héritage
et
> d'extension et je fait les constats suivants (peut-être erronés ?) :
>
> - Il n'est apparemment pas possible de mettre en place des blocks à
> l'intérieur de balise (exemple block autour de l'attribut class du body)
?
>
En théorie si. Si ce n'est pas possible c'est un bug.
Ok, je vais modifier et vérifier ça.
Cela dit, ça fait un peu bizarre d'avoir une balise <> à l'intérieur
d'une
autre balise <> et ça risque d'amener des interrogations du style : et
pourquoi on peut pas faire pareil avec les autres balises templates ? :-)
>
> - Je crois me souvenir qu'il n'est pas non plus possible d'avoir des
blocks
> dans les includes (via tpl:Include) ?
>
> Je ne sais pas si c'est possible, mais c'est déconseillé. En effet Twig
ne
le permet pas, ce serait bête d'utiliser/implémenter quelque chose qu'on ne
pourrait pas reconduire avec twig
Ok mais du coup on perd pas mal l'intérêt d'avoir de l'héritage au niveau
des "briques" qu'on inclut, du style _sidebar.html, _simple_entry.html,
etc...
Je comprends donc que c'est fromage OU dessert mais pas les deux :-/
> - J'ai créé un __layout.html qui reprend l'ancien home.html (qui lui est
> maintenant réduit à une ligne), puis j'ai tenté d'appliquer l'héritage
au
> template post.html : résultat, je me retrouve avec un post.html plus long
> (sic) que l'original, puisque quasiment tout le contenu diffère de
l'ancien
> home.html (y compris dans le head).
>
>
Tu as les fichiers disponibles quelque part ? Cela ne me choque pas que le
fichier post.html soit plus gros, le but de l'héritage est surtout de ne
pas répéter la même chose dans les fichiers, pas forcément de faire des
fichiers plus courts. Accessoirement, ça facilite aussi la vie aux plugins.
Je vais commiter tout ça une fois que j'aurais fait le tour (mais je peux
faire un zip de ce qui est d'ores et déjà fait, si besoin).
> Du coup l'avantage procuré par ce nouveau système me paraît bien réduit,
ou
> alors je n'ai pas compris comment fonctionne réellement ce système et la
> façon de s'en servir. De plus, certaines parties isolables des templates
> sont déjà dans des includes (sidebar, top, footer, ...), du coup pas
> vraiment
> besoin non plus d'héritage ici.
>
Pour l'avantage procuré par le nouveau système, c'est simple : aujourd'hui,
pour le plugin contact, le template d'affichage de la page repose sur le
thème par défaut. Si on utilise un autre thème qui a d'autres templates, on
doit adapter le template de contact. Avec l'héritage, on dit simplement "je
réutilise le template qui affiche un élément seul, et je spécialise son
contenu". Plus besoin de l'adapter (sous réserve que le thème initial
fournisse le bon contenu).
J'suis pas tout à fait d'accord, parce que le plugin contactMe possède lui
aussi autant de jeux de template qu'il en existe. De plus la majeure partie
des templates (head ET body) dépend du contexte et il y a en fait très peu
de choses en commun. J'ai été très étonné de constater que 80% du head, par
exemple, est spécifique au contexte. Quant à ce qui est en commun, c'est
déjà séparé dans des "briques" à part (_sidebar.html, ...).
>
> Autre interrogation :
>
> J'ai pour le head, un bloc qui englobe tout son contenu, puis à
l'intérieur
> de celui-ci plusieurs (sous-)blocks pour chacune des parties qui peuvent
> varier (titre, meta, dubin.core, link rel). J'ai besoin, pour post.html,
de
> redéfinir chacun des sous-blocks, ce que j'ai fait, ET de rajouter du
> contenu au block complet. Il y a-t-il un ordre requis, si seulement cette
> manip' est possible ?
>
Aucun problème de ce point de vue-là : tu enrichis tes sous-blocks de
manière standard, et le bloc englobant comme ça :
<tpl:Block name="englobant">
contenu spécifique ici
{{tpl:parent}}
contenu spécifique ici
</tpl:Block>
Ok pour la façon d'enrichir, mais faut-il utiliser un ordre particulier ?
D'abord les "sous-blocks" puis ensuite le "block" englobant, ou
l'inverse,
ou ça n'a pas d'importance ?
--
Franck