Great!

As we think about moving widgets into its own package/library, one of the big questions will be what is the API for other projects (like the notebook) to integrate widgets. I don't know how it affects this PR design but it would be nice if "widgets were just another package" that could be used with the notebook. Because of this I am hesitant to hardwire widget abstractions to the details of the notebook. In some ways, splitting widgets into a separate repo will be the right point to test that these abstractions make sense...

Looking at this some more, I think I'm going to try to move as much of the persistence as I can into the widget manager (almost all of the code in notebook.js).

Hey guys, I've changed this so almost all of the moving parts are isolated to the widget framework, cool! Here's some working code that persists all widgets, visible or not and with live comms, across page refresh.

The widget_manager.get_state method is configurable so you can change the persistence behavior in your persistence implementations:

    WidgetManager.prototype.get_state = function(options) {
        // Get the state of the widget manager.
        //
        // This includes all of the widget models and the cells that they are
        // displayed in.
        //
        // Parameters
        // ----------
        // options: dictionary
        //  Dictionary of options with the following contents:
        //      only_displayed: (optional) boolean=false
        //          Only return models with one or more displayed views.
        //      not_alive: (optional) boolean=false
        //          Include models that have comms with severed connections.

Edit: Removed example.

Can you rebase this now that #6664 is merged?

Rebased halfheartedly ... probably very broken at this point. Waiting on Promises PR which should be merge first- and will cause a lot of rebase pain for this PR.

Waiting on #6818

Squashed, rebased, and promisified... Let us see what Travis thinks.

Needs more promisification...

Updated example code:
Edit: removed

The tests are passing, but I don't think this is quite ready yet. Still a couple of details to work out about event order.

I added a convenience API, so now in addition to custom manager set_state/get_state based loading logic, you can do something as simple as the following to persist widgets to session data:

%%javascript
require(['widgets/js/manager'], function(manager) {
    manager.WidgetManager.set_state_callbacks(function() { // Load
        return JSON.parse(sessionStorage.widgets_state || '{}');
    }, function(state) { // Save
        sessionStorage.widgets_state = JSON.stringify(state);
    });
});

Rebased

Rebased again. Anyone interested in reviewing more? @minrk maybe?

I've had a look through, and it seems sensible. If @jasongrout and @jdfreder are happy with it, I think it's good to go. Needs rebase first, though.

@minrk rebased

@minrk submodule commit fixed, I amended my last commit with the correction.

Great, thanks!