Yes, but my argument is that, in that case, we have a pre-existing problem, because we should be explicitly running an addBinding for every binding we have, as I read the code. Therefore I decided to go for the "explicit error we can debug more easily rather than a silent error we'll never know about" route. Do you agree with this, but request that I add a comment to this effect; or disagree, and argue for more defensive code here?
This module subscribes to the valueChanged event. I think the dependency rightly belongs here, because of that. Perhaps it would be the right thing to do to remove the dependency in the inspector module, given my argument. WDYT?
Not if the module I test (databinding) itself depends on this, IMO. I only agree with you if I revert the event-valuechange dependency in databinding, but I think that the dependency arrangement I have in my branch is better than the one in trunk in this regard. Agree?
Hi Rick. Thank you very much for the review. I have a few points I'd like to negotiate on. Please see below.
On Sep 7, 2013, at 7:36 AM, Richard Harding <email address hidden> wrote:
> LGTM with notes below. Will QA in a sec. /codereview. appspot. com/13385045/ diff/1/ app/views/ databinding. js databinding. js (right): /codereview. appspot. com/13385045/ diff/1/ app/views/ databinding. js#newcode62 databinding. js:62: return (normalizedValue === currentValue);
>
>
> https:/
> File app/views/
>
> https:/
> app/views/
> should we refactor this out into any _stringEq or something since it's
> duped in the three eq methods?
Yeah, I agree we need something like that. I'll think on it and do something like this before landing.
> /codereview. appspot. com/13385045/ diff/1/ app/views/ databinding. js#newcode688 databinding. js:688: if (nodeHandler. eq(e.target, get(model) )) {
> https:/
> app/views/
> binding.
> will this blow up if no binding was found matching key?
Yes, but my argument is that, in that case, we have a pre-existing problem, because we should be explicitly running an addBinding for every binding we have, as I read the code. Therefore I decided to go for the "explicit error we can debug more easily rather than a silent error we'll never know about" route. Do you agree with this, but request that I add a comment to this effect; or disagree, and argue for more defensive code here?
> /codereview. appspot. com/13385045/ diff/1/ app/views/ databinding. js#newcode875 databinding. js:875: 'event- valuechange' ]
> https:/
> app/views/
> is this required in this module? It's used in the inspector I believe,
> but not here.
This module subscribes to the valueChanged event. I think the dependency rightly belongs here, because of that. Perhaps it would be the right thing to do to remove the dependency in the inspector module, given my argument. WDYT?
> /codereview. appspot. com/13385045/ diff/1/ test/test_ databinding. js databinding. js (right): /codereview. appspot. com/13385045/ diff/1/ test/test_ databinding. js#newcode26 databinding. js:26: 'model', 'model-list', simulate' ];
> https:/
> File test/test_
>
> https:/
> test/test_
> 'node-event-
> this needs the event-valueChange since you are binding with that event
> below.
Not if the module I test (databinding) itself depends on this, IMO. I only agree with you if I revert the event-valuechange dependency in databinding, but I think that the dependency arrangement I have in my branch is better than the one in trunk in this regard. Agree?
Thanks again!
Gary
> /codereview. appspot. com/13385045/ /code.launchpad .net/~gary/ juju-gui/ databindingChan gedValues/ +merge/ 184407
> https:/
>
> --
> https:/
> You are the owner of lp:~gary/juju-gui/databindingChangedValues.