- From: Rafael Weinstein <rafaelw@google.com>
- Date: Wed, 8 Feb 2012 15:33:29 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Erik Arvidsson <arv@chromium.org>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Henri Sivonen <hsivonen@iki.fi>, Ian Hickson <ian@hixie.ch>
On Wed, Feb 8, 2012 at 3:16 PM, Adam Barth <w3c@adambarth.com> wrote: > On Wed, Feb 8, 2012 at 2:47 PM, Rafael Weinstein <rafaelw@chromium.org> wrote: >> Here's a real-world example, that's probably relatively simple >> compared to "high traffic" web pages (i.e. amazon or facebook) >> >> http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962&content-type=text%2Fplain >> >> that produces each page of the chrome extensions API doc, e.g. >> >> http://code.google.com/chrome/extensions/contextMenus.html >> >> This uses jstemplate. Do a search in the first link. Every time you >> see "jsdisplay" or "jsselect", think <template>. > > It's a bit hard for me to understand that example because I don't know > how jstemplate works. Sorry. This example wasn't really meant to be understood so much as observed for: 1) A general feel for levels of nesting. 2) That the nested components are defined where they are used. 3) How complex the templating already is, even given that templates can be nested. 3) Imagine what this page might look like if each nested component was pulled out and put somewhere else (possibly the top level). > > I'm just suggesting that rather than trying to jam a square peg > (<template>) into a round hole (the HTML parser), there might be a way > of reshaping both the peg and the hole into an octagon. I get that. Unfortunately, I'm useless on this front because I know next to nothing about HTML parsing. All I can offer is an opinion as to how well various declarative semantics will address the templating use case. Maybe the best analogy I can give is this: try to imagine if someone proposed that C looping constructs couldn't contain a body -- only a function call. e.g. for (int i = 0; i < count; i++) doMyThing(); You can still write all the same programs, but it'd be an unfortunately feature to give up. > > Adam > > >> On Wed, Feb 8, 2012 at 2:36 PM, Adam Barth <w3c@adambarth.com> wrote: >>> On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson <arv@chromium.org> wrote: >>>> On Wed, Feb 8, 2012 at 14:10, Adam Barth <w3c@adambarth.com> wrote: >>>>> ... Do you have a concrete example of >>>>> where nested <template> declarations are required? >>>> >>>> When working with tree like structures it is comment to use recursive templates. >>>> >>>> http://code.google.com/p/mdv/source/browse/use_cases/tree.html >>> >>> I'm not sure I fully understand how templates work, so please forgive >>> me if I'm butchering it, but here's how I could imagine changing that >>> example: >>> >>> === Original === >>> >>> <ul class="tree"> >>> <template iterate id=t1> >>> <li class="{{ children | toggle('has-children') }}">{{name}} >>> <ul> >>> <template ref=t1 iterate=children></template> >>> </ul> >>> </li> >>> </template> >>> </ul> >>> >>> === Changed === >>> >>> <ul class="tree"> >>> <template iterate id=t1> >>> <li class="{{ children | toggle('has-children') }}">{{name}} >>> <ul> >>> <template-reference ref=t1 iterate=children></template-reference> >>> </ul> >>> </li> >>> </template> >>> </ul> >>> >>> (Obviously you'd want a snappier name than <template-reference> to >>> reference another template element.) >>> >>> I looked at the other examples in the same directory and I didn't see >>> any other examples of nested <template> declarations. >>> >>> Adam
Received on Wednesday, 8 February 2012 23:34:01 UTC