Le 24 février 2014 11:05, Bruno <dsls(a)morefnu.org> a écrit :
>
> 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 :-/
>
Twig propose une balise alternative qui répond à ce besoin : embed (
http://twig.sensiolabs.org/doc/tags/embed.html )
S'il le faut, je peux voir comment faire pour l'implémenter.
Je vais regarder ce que fait cette balise...
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).
>
Je veux bien voir à quoi ça ressemble :)
Je te fais un zip (en pièce jointe, __layout.html, home.html, post.html et
_sidebar.html, là où j'en étais hier)
> 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, ...).
>
Exemple avec Freshy2 : le contenu du formulaire doit être dans un <div
id="page"><div class="container"><div
id="frame"><div id="content"><div
class="post">. Si on avait de l'héritage, Freshy2 n'aurait pas à
fournir un
contact_me.html spécifique, il suffirait à contactMe de dire de faire comme
"post.html", en remplaçant le bloc "post-content" par le formulaire,
et en
supprimant le bloc "comments", et en renseignant un header spécifique à la
page de formulaire de contact.
Soit spécifier, en plus de l'héritage, à peu près 95% du template, ça
commence à faire beaucoup non ?
Parce que il faut reconnaître qu'on perd en lisibilité en utilisant
l'héritage. Un template héritant redéfinit, dans notre cas, la quasi
totalité des blocks, et on les aligne les uns derrière les autres en
perdant au passage leur "situation" dans le markup final.
Cela dit, peut-être que je n'implémente pas ça de la bonne manière, ie en
tenant compte de la "philosophie" du système d'héritage/extension ?
> 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 ?
>
Aucune importance, a priori, vu que la lecture et le rendu des blocs sont 2
phases distinctes.
Ok, c'est noté. Merci.