Sorry for the duplicate Marcin, I messed up on 'reply-all'.
On Mon, Mar 24, 2014 at 1:05 PM, Marcin Warpechowski <[email protected]>wrote: > 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. > IMO, you are using a sledge-hammer where you need a fly-swatter. (1) Using binding reflection so you can pass a static value in mustaches and pull it back out is wildly inefficient. (2) Setting a property from a string path is a basic operation, you don't really need a 'parser'. There used to be a public method for doing this provided by MDV, but I can't find it now. If you used Polymer, you would have two-way binding support, and this would be much easier. > > > 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]> 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]>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/bench >>>>>> mark/index.html >>>>>> >>>>>> and the codereview-diff.html benchmark(with O.o enabled) by about >>>>>> 15%: >>>>>> >>>>>> https://github.com/Polymer/TemplateBinding/blob/master/bench >>>>>> mark/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/540d6fd3-dc16-4a4b-becf-394062f24b8f%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/540d6fd3-dc16-4a4b-becf-394062f24b8f%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/CAHbmOLaYuTbiLYXTEYV8X9UPJJUxJ9TvhF4YujbdFu1exORjJA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
