To me, the promise of Polymer is to use the DOM as representative an engine of application state. To that end, one area that I'm a bit unclear about is what to do when I want to use template and mdv semantics to create things in the Light DOM. Let me give an example...
Let's say I have a sidebar like in Google Groups that is listing categories. I would probably construct an element like <category-list> and perhaps also a <category-item> that would be able to use AJAX to fetch the list of categories and then display them. This is easy enough with Shadow DOM: <template> <core-ajax url="http://some.url"; auto response="{{categories}}" ></core-ajax> <template repeat="{{category in categories}}"> <category-item category="{{category}}" on-click="{{openCategory}}" ></category-item> </template> </template> So far so good. The problem here is that it would actually be quite useful to my application if all of those <category-item> elements lived in the Light DOM. I could bind events to individual categories or highlight one based on pushState URL changes, etc. I might even be able to alter attributes of the individual category and save them back. Hiding all of the children in the Shadow seems like a less-than-ideal situation, but I don't know of another way to do it without manually instantiating each node and using appendChild (and therefore losing all benefits of MDV and data binding). Is there a convention for this? What should the right pattern be here? Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/c1b45f02-d3e6-4028-a905-998dbcce548c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
