It seems that you pasted the wrong link. I am curious to see your solution!
On Monday, March 24, 2014 8:28:57 PM UTC+1, Scott Miles wrote: > > Sorry for butting in, but why not do this the more obvious way? > > http://jsfiddle.net/warpech/RZtLA/ > > > On Mon, Mar 24, 2014 at 12:16 PM, Marcin Warpechowski > <[email protected]<javascript:> > > wrote: > >> Hi Rafael, >> thanks for describing the motives behind this change and your work on >> improving the performance and the API. >> >> Actually, I have a use case for point 3) - a need to programatically >> change Node binding value. >> >> In my app, I need to have buttons that change the value of a model >> property. With the exposed `bindings_` property, it is quite easy to >> achieve that. See the fiddle: http://jsfiddle.net/warpech/RZtLA/ . The >> HTML is not the cleanest, but the best we came up with. >> >> Your recent changes to move `bindings_` behind a flag made me realise >> that using it is a poor way to achieve what I need. Yet, I haven't found a >> better solution. Would you propose more reliable solution to change bound >> values with a button? >> >> cheers >> >> >> >> On Tuesday, March 18, 2014 12:10:30 AM UTC+1, Rafael Weinstein wrote: >> >>> Ok. These changes are now on trunk (master) of NodeBind. >>> >>> >>> On Fri, Mar 14, 2014 at 8:59 PM, Rafael Weinstein <[email protected]>wrote: >>> >>>> I've implemented (2) & (3) and created a new branch which contains the >>>> changes: >>>> >>>> https://github.com/Polymer/NodeBind/tree/noUnbind >>>> >>>> (here's the CL: https://codereview.appspot.com/76140044/). >>>> >>>> This change improved the binding benchmark (at 100% density with O.o >>>> enabled, but no compound bindings or expressions) by about 35%: >>>> >>>> https://github.com/Polymer/TemplateBinding/blob/master/ >>>> benchmark/index.html >>>> >>>> and the codereview-diff.html benchmark(with O.o enabled) by about 15%: >>>> >>>> https://github.com/Polymer/TemplateBinding/blob/master/ >>>> benchmark/codereview-diff.html >>>> >>>> I leave it to Scott & Steve to let me know when/if Polymer-dev would >>>> like to integrate this change (by not using unbind/unbindAll anymore). >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Mar 9, 2014 at 10:23 AM, Rafael Weinstein <[email protected]>wrote: >>>> >>>>> Hello all, >>>>> >>>>> I'd like to propose two repo/design changes: >>>>> >>>>> 1) Merge the NodeBind Repo into TemplateBinding. >>>>> >>>>> This will basically mean just moving the source & tests from NodeBind >>>>> into TemplateBinding. This doesn't really change the design of the system >>>>> (at least yet), but it does acknowledge that these two things really go >>>>> together. It's one less repo to deal with and it means that we can >>>>> eventually write a single pseudo-spec for the whole system and have it be >>>>> in one place. >>>>> >>>>> 2) Remove Node.prototype.unbind, Node.prototype.unbindAll. >>>>> >>>>> It's somewhat less clear to me that nodes should ever be unbind-able >>>>> (rebind-able, or imperatively bind-able beyond template instancing, for >>>>> that matter). The only use-case we've encountered for doing this is >>>>> cleaning up (shutting down observation). However, if WeakRefs become >>>>> available in ES or if TemplateBinding/NodeBind get standardized (and >>>>> therefore make weak references available from c++), cleaning up >>>>> observation >>>>> can be a concern of the node itself, and not require external interaction. >>>>> >>>>> Thus, the current design where Node.prototype.bind() is returning a >>>>> "close-able" object is really only internal API for the prollyfill. >>>>> >>>>> The main motivation for doing this is perf. Unbinding and setting up >>>>> the .bindings object during construction are significant work. >>>>> >>>>> I know that Polymer is currently using unbind and unbindAll(), but my >>>>> proposal is for polymer to do what TemplateBinding does, which is to keep >>>>> an array of closeable objects for each fragment that will eventually need >>>>> to be cleaned up, rather than traverse a fragment and unbind all nodes. >>>>> >>>>> 3) Make Node.prototype.bindings run-time enable-able. >>>>> >>>>> Again, this is significant work for which I know of only one use case >>>>> (which is tooling -- e.g. the sandbox app). >>>>> >>>>> I propose that we allow the bindings of a Node to be reflectable only >>>>> if some well known switch is enabled. This is analogous to devtools using >>>>> internal APIs to enable reflection. >>>>> >>>>> Concerns? >>>>> >>>>> >>>>> >>>> >>> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/bd348702-cc39-4f29-9172-fa902eb0b134%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/bd348702-cc39-4f29-9172-fa902eb0b134%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/b4437eac-d3e9-4cec-a484-262c0991ad26%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
