Re: Model-driven Views

On Wed, Apr 27, 2011 at 08:33, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> Not sure why this had some relation with XBL. Unless you are
> planning to put the template based DOM nodes to anonymous DOM.

The relation to XBL is that XBL has a template element and inside it
you can "bind" attributes and content to the host element's attributes
and content. We feel that the same concept can be useful outside of
XBL and that we would like to provide a more generic solution that
something like XBL can then reuse.

> - "Child nodes are not considered to be a part of the DOM. During
>  parsing, they are lifted out..." Huh, you really want to alter HTML
>  parsing?
>
> - "If a template element is created via script, any children are
>   removed and attached to the instancePrototype when the template
>   element is attached to a document." What if the template is already
>   in DOM when the new child elements are added.
>   It sounds *very* strange to add new special cases to DOM Core
>   methods.

I feel like the document reflects too much what we ended up doing in
the prototype. Lets backup and look at the problems we are trying to
fix here.

1. We want <template> to be able to contain arbitrary content that is
used as the content of the instances that are created from it. Now
assume that the template element contains some active content such as
<audio autoplay>, script or simply just an image. We don't want the
audio to start playing, we don't want the script to run inside the
template element and we don't want the image to be requested at this
point.

2. We also want to allow place holders to make it easier to write your
templates. Before the template content has been instantiated the
content is incomplete or invalid. For example img@src might contain a
place holder:

<template iterate>
  <img src="{{data.src}}.png">
</template>

It is important that we don't try to request "{{data.src}}.png".

3. The last issue we are trying to provide a solution too is with DOM
access, specifically with getElementById, querySelector etc. It is
highly unlikely that the user wants to get to the content inside the
template element. What they usually want is to get access to the
template instance. For example:

<div id="a">
<template instantiate>
  <p id="b">{{ data }}</p>
</template>
</div>
...
<script>
document.getElementById('a').model = {data: 'Hello World'};
assertEquals('Hello World', document.getElementById('b').textContent);
</script>

In the prototype we got around most of these issues by just moving the
content DOM out of the template element.

An alternative solution would be to treat <template> more like
<script> and treat the content as CDATA. This would require some more
work over <script> because we need to allow nested <template> but that
seems acceptable. The downside to this solution is that we want people
to be able to build template elements on the fly using plain old DOM
core.



> - What kind of property is instancePrototype? NodeList?

It is not exposed. Internally we used a list of Nodes.

> - What does this mean
>  "Any instances of a template must exist as a sequence of nextSiblings
>  following the template element itself, with each instance being
>  terminated by a HTMLTemplateInstanceElement."
>  I couldn't see any <templateinstance> elements in the examples.

The idea is that instances become siblings to the template element.

The HTMLTemplateInstanceElement is an artifact of an older design.
Between every set of instance nodes we want there to be a delimiter.

<template iterate="list"><a/><b/></template>
<a/><b/>
<!-- delimiter -->
<a/><b/>
<!-- delimiter -->
...

The main motivation for having a delimiter is to allow script to add
and remove nodes to instances. With delimiters we can tell what nodes
belong to each instance, even if they were not added by the template
iterator.  This allows the template iterator to know what to move and
remove when items in the collection are moved and removed.

Our initial design had an element (with display:none) but making that
into a comment has some benefits. For example it does not break CSS
sibling selectors, DOM nextElementSibling, children, etc all work as
expected.

Sorry I didn't address all your comments/questions but this is already
getting long. We'll follow up with another email trying to answer the
other questions.

-- 
erik

Received on Wednesday, 27 April 2011 18:19:28 UTC