Skip to content

Conversation

@SylvainCorlay
Copy link
Member

This is a simple fix for #6814. In general, whenever a widget model may be modified by both the backend and the frontend, if there is a validation stage that transform the set values, the logic should be implemented on both sides.

On this regard, but outside of the scope of this small PR:

  • I don't think that what we currently have for the validation of values in widgets is good enough, because the validation happens AFTER we set the value, and it does not prevent the assignment.
  • Ideally, we should be able to hook up the custom validation logic in the traitlet validation, via the traitlet type metadata, so that in case of error, the assignment does not actually happen.

@jdfreder jdfreder added this to the 3.0 milestone Jan 27, 2015
@jdfreder
Copy link
Contributor

Thanks @SylvainCorlay . I see you opened #7603 too, I still think this should get merged regardless, for 3.0 .

@SylvainCorlay
Copy link
Member Author

Yes I think too. I doubt the other logic will replace this one for IPython 3.0.

@jdfreder
Copy link
Contributor

@SylvainCorlay I've checked out this branch and I'm testing it now. The code looks a-okay to me.

@jdfreder
Copy link
Contributor

@SylvainCorlay this does fix the problem @ssunkara1 reported, but I did find another problem. I haven't checked if it exists in master too or if it's a result of this fix.

a.min = 20
a.value = 50
print(a.value)

50

%%javascript
element.log(a.get('value'));

50

a.value = 10
print(a.value)

20

%%javascript
element.log(a.get('value'));

50

The Javascript value is out of sync with the Python value. It should log 20...

@jdfreder
Copy link
Contributor

My IPython logging convenience function:

%%javascript
/**
 * Log to a notebook cell for easy reading.
 *
 * Usage:
 * %%javascript
 * element.log('hello world!');
 */
element.constructor.prototype.log = function() {
    for (var i = 0; i < arguments.length; i++) {
        this.append($('<div/>').text(String(arguments[i])));
    }
};

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use the _max_changed name instead of defining the method and registering it manually?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was simply replicating the logic from _BoundedInt in _BoundedFloat. I can change that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now using _max_changed, _min_changed and _value_changed.

@jdfreder
Copy link
Contributor

Thanks @SylvainCorlay !

@jdfreder
Copy link
Contributor

It looks like there's a legitimate test failure.

@jdfreder
Copy link
Contributor

I think now that you're using the _X_changed syntax, validation is occurring earlier and that's causing the failure. Strange, the default values should pass validation...

@SylvainCorlay
Copy link
Member Author

I can reset to the previous commit if it is fine with you. It is possible that the validation happens even before all the default values are set, which would explain the failure.

@jdfreder
Copy link
Contributor

It seems that may be a better idea than using a lock to prevent validation until after initialization. I'm going to take a quick look...

@jdfreder
Copy link
Contributor

@SylvainCorlay ah it was just a typo: SylvainCorlay#1

@minrk
Copy link
Member

minrk commented Jan 27, 2015

If there's a good reason for it to not use the _foo_changed, that's fine. I just didn't see the reason.

@takluyver
Copy link
Member

Test failures look real.

@jdfreder
Copy link
Contributor

Sorry for the trouble @SylvainCorlay , I thought those typos were the problem. At this point I think it's best to revert back to 200775b because I think my original evaluation of the problem was right (validation is occurring too early now).

@SylvainCorlay
Copy link
Member Author

ok, let me do that - and rebase.

@jdfreder
Copy link
Contributor

@SylvainCorlay looks like the commit got credited to me even though I haven't done anything :P . Do you want to fix that before we Travis&merge?

@SylvainCorlay
Copy link
Member Author

@jdfreder I rebased the whole thing to 2 commits:

  1. use _**_change and do the correct validation, amended as yours.
  2. switch to other regular handlers.

@SylvainCorlay
Copy link
Member Author

It is funny how an old inline comment on an outdated diff is displayed again.

@SylvainCorlay
Copy link
Member Author

@jdfreder green button?

jdfreder added a commit that referenced this pull request Jan 27, 2015
@jdfreder jdfreder merged commit ea6167e into ipython:master Jan 27, 2015
@jdfreder
Copy link
Contributor

🍏

@SylvainCorlay SylvainCorlay deleted the fix_slider branch January 27, 2015 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants