I don't know what is scarier. The fact that I'm prying into the guts of OpenJUMP's GUI, or the fact that I understand almost half of the code I read there. :]
I think we've got a small problem with the chain-of-execution that occurs when a TaskFrame in OpenJUMP is closed. I've spent over an hour looking at the source code, and I think we can clarify the execution path when a TaskFrame is closed. A short description of the problem is below. I'll try to post a longer version on the wiki. - The user triggers the addition of a TaskFrame to the WorkbenchFrame through some interaction with the GUI. - The WorkbenchFrame.addTaskFrame method is called. This eventually triggers the call to the WorkbenchFrame.addInternalFrame method. - The WorkbenchFrame.addInternalFrame method calls the WorkbenchFrame.setClosingBehavior method on the TaskFrame that is to be added. - The WorkbenchFrame.setClosingBehavior method creates a new InternalFrameAdapter object from an internal or hidden class defined in the WorkbenchFrame. This adapter triggers the close method of the InternalFrameCloseHandler method that is currently stored by the WorkbenchFrame. Although I don't yet know how this InternalFrameCloseHandler is created and set in the Workbench, I do know that the same InternalFrameCloseHandler is called by all TaskFrames added to the Workbench. This means, in essence, that the close method of the InternalFrameCloseHandler controls the closing behavior of all TaskFrames. This wouldn't be a big problem, but, the TaskFrame class also defines a internal/hidden class that is an instance of InternalFrameAdapter. It appears that this listener is registered with the TaskFrame in its constructor. It also listens for close events on the TaskFrame. Here is the problem: As a core programmer, how do I modify the behavior that occurs when a TaskFrame is closed? Do I do this by modifying the TaskFrame class or an extension of the TaskFrame class? Or do I instead modify the InternalFrameCloseHandler that is registered with the TaskFrame for the Workbench? I really think it would be best to have the closing behavior handles by the TaskFrame, and not by the InternalFrameCloseHandler class. That way a programmer could create an extension of the TaskFrame class, or other LayerManagerProxy implementation that had custom closing behavior. If you modify the closing behavior using the InternalFrameCloseHandler you modify the closing behavior for all Tasks. We currently have code that controls the closing behavior of TaskFrames in three places. [1] The WorkbenchFrame.closeTaskFrame method. [2] The InternalFrameCloseHandler interface. [3] The TaskFrame.InternalFrameAdapter.internalFrameClosed method. I'd like to see us extract the hidden TaskFrame.InternalFrameAdapter class to an external TaskFrameAdapter class and then move most of the closing logic in the three methods to just the internfalFrameClosed method of this new class. This would clearly identify a single location to modify the clsoing behavior of TaskFrames and would allow programmer's to have unique closing behavior for different types of TaskFrame/LayerManagerProject objects. I know what you are thinking...Why are we worried about this? Who will ever need to modify the closing behavior of a TaskFrame? I think we should worry about it because it is ugly code, for one thing. Secondly, I need to modify the closing behavior right now as part of my Docking Window Framework integration. What about another programmer that wants to commit updates to a database or web server directory when a task is closed? Or what if he wants to ask the user to store information on his dataset edits before closing a task? The changes I propose would allow this type of customization to occur in a much cleaner manner. Waiting for your thoughts, comments, and suggestions. The Sunburned Surveyor ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
