This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It doesn't do anything useful that I can see. If a node is "destroyed", typically that will mean nothing more than that its parent's list of children is refreshed and will now not contain it. What else is supposed to happen? Who is supposed to call this method and when? Who is supposed to listen to it and why?
Note that sometimes, but not always, Node's will fireNodeDestroyed when their underlying object is deleted, with the result that an Explorer window *rooted* on that node will be closed automatically. Otherwise the call is pretty much useless since the node will just be removed from its parents anyway. The semantics of when and how it should be fired have never been clear IMHO, and most node impls do not use it consistently. Needs to be rethought for Looks, should not just blindly copy impl from Nodes.
Refined suggestion: fireNodeDestroyed or similar may still be called, but nothing should call it by default - specifically, refreshing children to no longer include a child object should *not* call it. Only the implementor of a particular look will know whether and when an object is really destroyed; removing it from one parent does not mean anything (it might still be a child of something else, or might be valid without a parent). The only code that listens to this event should be an explorer view (to close itself if the root is destroyed).
Hmm, we probably still need a way how to tell the visual layer that some data in the underlying datastructure disappeared. This is exactly what is fireNodeDestroyed(...) is for. The fireNodeDestroyed is a protected method in Look so the only caller should be the implemator of Look. For LookNodes firing nodeDestroyed refreshes parent node's children. Other views may handle it differently. So I see no issue here.
I still think the documentation or expected usage is not quite right, though perhaps the code is. I.e. Javadoc needs to be made explicit on this. IMHO there should be Look.fireNodeDestroyed (with a better name! please fix the name to not use the word "node", e.g. fireObjectDestroyed), and LookNode when receiving this should simply pass it on as Node.fireNodeDestroyed. That is enough to ensure that Explorer views rooted at that node are closed. In particular, LookNode should *not* try to refresh a parent node's children based on this event, as the Look is already required to fire refreshChildren() when a parent's list of children changes (whether or not this is due to a child being "destroyed"). Nor should either Look.destroy or LookNode.destroy call this method automatically; it is the responsibility of the Look to decide when an object is really destroyed.
Agree. Will do.
Done. Method is renamed to fireObjectDestroyed( ... ) in Look class. JavaDoc is updated to mention that there is no need to call thos method from Look.destroy() method. Jesse I couldn't find where LookNode tries to update parent's children I suppose the code is removed.
Yeah, as I think I said, the code was probably already OK - I was just trying to clarify how it should behave.
verified