Custom serialization #7757
Custom serialization #7757
Conversation
|
@jdfreder, @SylvainCorlay - this isn't nearly ready yet, but it's getting there. Just FYI |
|
I'll wait to try to wrap my head around the code entirely until it's in a working state, just ping when. |
| })(state[k])); | ||
| } | ||
| } | ||
| return utils.resolve_promises_dict(state); |
There was a problem hiding this comment.
The block above should get moved into it's own method.
There was a problem hiding this comment.
I agree; that's a bit of a beast.
There was a problem hiding this comment.
I rewrote it and think it's a lot easier to follow now.
|
My biggest gripe about this design is that custom serializers are required for any variation of nested traits and I would argue that that means this doesn't scale well. Additionally, as-is this supports |
|
The branch now minimally works for widget boxes (e.g., it correctly serializes and unserializes widget references). I'll look at your comments tomorrow. Thanks! |
|
@jdfreder - since any serializers/deserializers are supported, it would be easy to make default serializers that recurse into container traitlets, and thus experiment with different ways of doing things. |
|
@jasongrout I think this design is starting to shape up nicely. I'll need to experiment with this branch by writing some custom serializers to test it. |
|
@jdfreder - I'm also writing some custom serializers to test things out. Then I'll write some formal unit tests based on that. |
4d1810e to
2c9c7b4
Compare
|
Definitely looking forward to this one, hope I can learn from it and use it soon. |
|
Wow, lots of changes since the last time I looked. Everything is looking good so far. |
047bc09 to
3055eeb
Compare
|
Still have some errors; I'll look at these tomorrow, though. |
a19ad12 to
9d0c441
Compare
|
I'm going to split this into a typo fix, the kernel.js fix, and then the widget stuff, so that it's easy to finish the widget stuff even after The Big Split. |
|
@jasongrout that sounds perfect, thanks. |
9d0c441 to
0e93515
Compare
|
@jasongrout binary websocket tests don't pass, but it's unrelated to this PR. It's just the API change from the switch to memoryviews. I opened #8200 to fix it. |
|
I'm reviewing this now |
| if (module.hasOwnProperty(target_name)) { | ||
| if (endsWith(target_name, "View")) { | ||
| widgetmanager.WidgetManager.register_widget_view(target_name, module[target_name]); | ||
| } else if (endsWith(target_name, "Model")) { |
There was a problem hiding this comment.
I don't think we should be assuming, even within our own project, that the class name's suffix correlates to the parent class. Here's something I whipped up that can be used to check for inheritance of backbone classes:
require(['backbone', 'widgets/js/widget', 'widgets/js/widget_button'], function(backbone, widget, button) {
var isinstance = function(child, parent) {
child = child.__super__;
while (child !== null) {
if (child === parent.prototype) return true;
child = child.__proto__;
}
return false;
};
console.log(isinstance(button['ButtonView'], widget['DOMWidgetView']));
console.log(isinstance(button['ButtonView'], widget['WidgetView']));
console.log(isinstance(button['ButtonView'], widget['WidgetModel']));
});true, true, false
There was a problem hiding this comment.
class inheritance is a much better idea than working on the name. Does Backbone not have something like isinstance?
There was a problem hiding this comment.
I don't know, TBH I didn't look :(
There was a problem hiding this comment.
Looks like instanceof works- I haven't tested it yet though. http://stackoverflow.com/a/11125117
There was a problem hiding this comment.
@jasongrout yup, much simpler:
button['ButtonView'].prototype instanceof widget['DOMWidgetView']
//true
button['ButtonView'].prototype instanceof widget['WidgetView']
//true
button['ButtonView'].prototype instanceof widget['WidgetModel']
//falseThe trick is the .prototype .
|
@jasongrout overall I'm happy with this design too. If later we find that we need something more dynamic, like box typing that @SylvainCorlay suggested, we'll cross that bridge when/if we come to it. Just two comments inline. |
|
@jdfreder: I think I addressed your two points. Thanks! I'll wait to make sure the tests pass as well. |
|
@jdfreder: Looks like tests passed.... |
|
This does change the number of arguments in custom message callbacks; I'm not sure where to note that. |
|
Awesome! Go ahead and add a what's new rst in https://github.com/ipython/ipython/tree/master/docs/source/whatsnew/pr then I think this is 👍 |
|
Woohoo! |
|
@jasongrout IIRC you're on vacation right? Seems like we have an even greater timezone difference today! I'm going to merge this and write the what's new rst for you. |
|
@jdfreder @jasongrout it seems that it is breaking the loading of custom models. I am looking into this now. |
|
@SylvainCorlay, thanks. @jdfreder, thanks for moving ahead without waiting for me. One incompatible change is that the custom message handlers in python now take a new argument, |
|
@SylvainCorlay, also note that models which have fields that encode references to other models need to now explicitly declare the serializer for that field (like in widget_box's children attribute). This, for example, will necessitate some changes to pythreejs. |
|
@jasongrout thanks for the pointers. |
|
Right. I think that is much better than the hack we had in serialization before. |
|
I agree. Do you think that we still need the |
|
Probably less of a need. We could shorten it, but I don't think we should get rid of it. |
|
@tacaswell, I forgot to mention to you that this PR enables binary buffers in IPython comm messages, which may be useful to the nbagg backend. |
|
attn @pelson That does seem handy. This means we can send the png as binary rather than as a base64 string? |
|
Exactly |
This is an attempt to address #7729.
This depends on #7798, #7801, and #7780, which have all been merged.