MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Referring to Templates
As I noted before, when you refer to a declarative template in the FlipView or ListView controls, what
you’re actually referring to is an element, not an element id. The id works because the app host creates
variables with those names for the elements they identify. However, we don’t actually recommend this
approach, especially within page controls (which you’ll probably use often). The first concern is that only
one element can have a particular id, which means you’ll get really strange behavior if you happen to
render the page control twice in the same DOM.
The second concern is a timing issue. The element id variable that the app host provides isn’t created
until the chunk of HTML containing the element is added to the DOM. With page controls, WinJS.UI.-
processAll is called before this time, which means that element id variables for templates in that page
won’t yet be available. As a result, any controls that use an id for a template will either throw an
exception or just show up blank. Both conditions are guaranteed to be terribly, terribly confusing.
To avoid this issue with a declarative template, place the template’s name in its class attribute:
Then in your control declaration, use the syntax select("") in the options record, where
is anything supported by element.querySelector:
There’s more to this, actually, than just a querySelector call. The select function within the options
searches from the root of its containing page control. If no match is found, it looks for another page
control higher in the DOM, then looks in there, continuing the process until a match is found. This lets
you safely use two page controls at once that both contain the same class name for different templates,
and each page will use the template that’s most local.
You can also retrieve the template element using querySelector directly in code and assign the
result to the itemTemplate property. This would typically be done in a page’s ready function, as
demonstrated in the Grid App project, and doing so avoids both concerns identified here because
querySelector will be scoped to the page contents and will happen after WinJS.UI.processAll.
Template Elements and Rendering
The next interesting question about templates is, what, exactly, do we get when instantiating a WinJS.-
Binding.Template? This is more or less another WinJS control that turns into an element when you call
WinJS.UI.processAll. But it’s different in that it removes all its child elements from the DOM, so it never
shows up by itself. It doesn’t even set a winControl property on its containing element.
206