Pass the output area object in events specific to the output area.

[jasongrout]

Also, add a new event triggered right before the output area is cleared. This is useful if an output renderer has cleanup work to do before the DOM element is removed off of the page.

@gnestor and I both want to add mimebundle renderers that should have a method called when the rendered value needs to be cleaned up.

Passing the output area in also makes it easy to listen for this event at the notebook level once and perform some action on whatever output area triggers the event.

[jasongrout]

It would be even better if the cell could keep track of the rendered values, and take an optional callback for when that rendered value would be cleared. But we can hack around that with an event like this.

[gnestor]

This looks like a good solution to me. Are there advantages to attaching event handlers to the output element vs. the output area?

[jasongrout]

I'm not sure I understand your question. We trigger on the output element because that is what has the jquery event system because it is a jquery object. The bubbling then goes up through the DOM, so you can listen to all of these events by doing something like notebook.container.on('clearing', '.output', myhandler);.

[gnestor]

This looks like a good solution to me. Are there advantages to attaching event handlers to the output element vs. the output area?

What I mean is this.element.on('cleared', handler) vs. this.events.on('clear_output.CodeCell', handler) (which is actually the code cell, not output area).

Since the output element already has changed, cleared, and resizeOutput events, adding a clearing event makes sense.

[jasongrout]

1. We want to trigger for output areas, not code cells, since we might have output areas not associated with code cells (as in output widgets).

2. I can't find it now, but I thought at one point @minrk preferred having output area events on the output area, rather than global events. It doesn't matter to me either way - I'm essentially doing the same handler either way. @minrk, do you have a preference between events on the outputarea element instance vs. a global (but scoped) event?

[jasongrout]

I also figured keeping the events on the output area instance was more backwards compatible....

[rgbkrk]

Should ignore_queue have a default argument since prior calls to this would not have had an argument? Perhaps undefined is ok to pass through to this.output_area.clear_output?

[jasongrout]

Good call. I'll check.

[jasongrout]

It's fine the way it is. undefined is treated as false, which means things should proceed as normal in the clear_output function.

[rgbkrk]

Certainly better naming. 😄

[jasongrout]

It took me a while of staring at it to figure out the double negative logic and what it was supposed to say :).

[rgbkrk]

do you have a preference between events on the outputarea element instance vs. a global (but scoped) event?

I prefer global events that are scoped too.

[jasongrout]

I prefer global events that are scoped too.

I prefer that too, all else being equal, but was avoiding making too many huge changes, especially backwards-incompatible ones.