> > 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 -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
