RE: the "app root element", I tend to put the guts of my app in an auto-binding template (see here <https://github.com/robdodson/contacts-app/blob/master/app/index.html#L47>) and then use that as the starting point <https://github.com/robdodson/contacts-app/blob/master/app/scripts/app.js#L15> for my app. It doesn't solve the performance problems associated with MDV but hopefully 0.8 addresses some of those issues.
On Sun, Oct 26, 2014 at 2:43 PM, Michael Bleigh <[email protected]> wrote: > I've been thinking through how it might be possible to get some of the > common advantages of template binding without the need to do full-scale > MDV. This would have advantages for performance reasons, but would also in > my opinion help address the "App Root Element" issue that I keep running > into building my Polymer apps (wherein the entire application is absorbed > into a containing element for the sole purpose of getting template binding > semantics). Basically, it would introduce one to three new "magic attribute > prefixes" similar to the on-* event binding. It would work something like > this: > > <core-ajax bind-response="usercard" url="/users/abc" handleAs="json" > ></core-ajax> > <user-card id="usercard"></user-card> > > > Presuming that the user-card element is something that accepts a "model" > property with user data and displays something useful. The *bind-** > prefix would work in a two-way fashion similar to current mustache binding, > where everything after the "bind-" is considered the attribute or property > name to bind. There could also be *pub-** and *sub-** to exclusively > publish or exclusively subscribe to a value. > > The value of the magic attributes would be the id of an element in the > same document context as the bound element (i.e. retrieved using > this.ownerDocument.getElementById). This way shadow boundaries would be > respected and utilized appropriately. By default the "model" property would > be set on the target element; however, you could easily have a syntax like > "usercard.data" where a period denotes the separation between the DOM id > and the property name. > > This paradigm would solve the most common use cases I run into when > wanting to declaratively bind. It does *not* solve things like repeating > templates or things that can't have an id or a knowable-in-advance id for > some reason. What I like about it is that I can use these attributes > completely outside of Polymer's template binding setup. > > Not sure that this is perfect, but throwing it out for discussion after > thinking on it over the weekend. > > 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/42ce5f98-2231-4e85-ac79-a969794f2afc%40googlegroups.com > <https://groups.google.com/d/msgid/polymer-dev/42ce5f98-2231-4e85-ac79-a969794f2afc%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > 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/CAJj5OwDZZ6neCGX-4zTmVsdhwd%2BV%3DuhfuuUz_9u7FxZF2NAcUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
