I see your point. Indeed, it looks simple until you want to bind to a
deeper level value, say bind="user.firstName". In such case there would
need to be a parser to find the correct path in the model. Something
like: http://jsfiddle.net/warpech/RZtLA/6/
In my original code, I tried to reuse the binding facilities of NodeBind
and its parser. Also, I liked the fact of consistent usage of {{ }} for
property binding.
On Monday, March 24, 2014 8:36:01 PM UTC+1, Scott Miles wrote:
>
> Er, http://jsfiddle.net/RZtLA/5/
>
>
> On Mon, Mar 24, 2014 at 12:28 PM, Scott Miles <[email protected]<javascript:>
> > 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/540d6fd3-dc16-4a4b-becf-394062f24b8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
