Re: [webcomponents] HTML Parsing and the <template> element

Are you essentially suggesting partials?  Basically, one template can
contain another only by reference?  Then you have something like a
corresponding tag or macro-ish thing whereby you can reference
(functionally include) on themplate from another?

That sidesteps the whole nested template parsing pretty nicely and its what
a lot of logicless template approaches do.
 On Feb 8, 2012 6:34 PM, "Rafael Weinstein" <rafaelw@google.com> wrote:

> 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 Thursday, 9 February 2012 01:21:31 UTC