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 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 :)
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.
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.
--
Bruno