1 person found this helpful
No. You don't need explicit cleanup in this case: if your outerDocument is going away, you have nothing to worry about. The event handler leak can happen in sort of the reverse situation: suppose you have a long-lived MyView that contains a custom DataGrid like the one below. Now suppose that MyView frequently destroys and re-creates the grid. And suppose that on its creationComplete event, the grid registers a listener for outerDocument's (MyView's) enterFrame Event. Unless you explicitly remove this listener, MyView will still have a reference to it even after the grid that registered the listener is destroyed (and garbage collected).
This is a pretty contrived example, but it sort of illustrates the potential for leaks: a certain component is elligible for garbage collection, but some longer-lived component holds a reference to it (or part of it, such as a listener function). If the longer-lived component is elligible for GC as well, you don't really need to worry about proper cleanup. That's what you're paying the GC processor cycles for.
Let's be careful here. It is true that cleanup is not needed, but in the
code snippet provided, outerDocument is implied to be a .mxml file that
contains the DataGrid and its in-line components because the references from
the renderer are to a function in a script block that is not defined within
Even if the outerDocument is not destroyed and only the renderers are being
created and destroyed, the code as written will not cause a leak because the
renderer is referencing the outerDocument and not the other way around.
And that is because the code in an event handler block is not a request to
add an event listener to outerDocument, it is simply a method body of a
handler attached to an object in the renderer.
What would cause a leak is a call to outerDocument.addEventListener.