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]>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].
> 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/CAHbmOLbXxBxu5vm_J0VvAZgLUSMne%2BqRKXie7DJqdzNVO8PKRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to