Le 24 février 2014 11:05, Bruno <[email protected]> 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.
-- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
