I've been doing some work on the Union By Attribute Plug-In. One of the first thing I tried to identify when I began working with the program was the execution path. I started by taking a look at the plug-ins execute method. In this plug-in, the execute method only displayed the dialog to collect the parameters from the user needed to peform the union operation. After that, I lost the path of execution. I knew that the union method did the main work of the plug-in, but I couldn't figure out how it got called from the execute method.
The "open call hiearchy" tool in Eclipse may have provided the answer. Here is what I believe is the execution path of the UnionByAttributePlugIn class:
(1) The TaskMonitorManager. execute method is called. It receives an instance of a ThreadedPlugIn class as an argument, which is in this case the UnionByAttributePlugIn.
(2) The TaskMonitorManager.execute method creates a TaskWrapper object. The run method of the TaskWrapper object is then called.
(3) The TaskWrapper.run method calls the UnionByAttributePlugIn.run method.
(4) The UnionByAttributePlugIn.run method calls the UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method.
(5) The UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method calls the UnionByAttributePlugIn.union method, which does the main work of the plug-in.
I still haven't figured out the direct link between the execute method and the TaskMonitorManager. I'll be working on that. It would be nice if the path of execution was a little more clear in the execute method. This is something to remember when writing your own plug-ins for OpenJUMP. Try to keep a direct link between your plug-ins execute method and the methods that do the main work of your plug-in. One way this can be achieved is by putting your code to display and collect data from a GUI in its own method that is called from execute. Here is an example:
public boolean execute(PlugInContext context)
{
this.showGUI();
boolean workDoneSuccessfully = this.doWork();
return workDoneSuccessfully;
}
I hope to write more on this blog about the TaskMonitorManager class, TaskWrapper class, and threads in OJ as I learn more about them.
The Sunburned Surveyor
The "open call hiearchy" tool in Eclipse may have provided the answer. Here is what I believe is the execution path of the UnionByAttributePlugIn class:
(1) The TaskMonitorManager. execute method is called. It receives an instance of a ThreadedPlugIn class as an argument, which is in this case the UnionByAttributePlugIn.
(2) The TaskMonitorManager.execute method creates a TaskWrapper object. The run method of the TaskWrapper object is then called.
(3) The TaskWrapper.run method calls the UnionByAttributePlugIn.run method.
(4) The UnionByAttributePlugIn.run method calls the UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method.
(5) The UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method calls the UnionByAttributePlugIn.union method, which does the main work of the plug-in.
I still haven't figured out the direct link between the execute method and the TaskMonitorManager. I'll be working on that. It would be nice if the path of execution was a little more clear in the execute method. This is something to remember when writing your own plug-ins for OpenJUMP. Try to keep a direct link between your plug-ins execute method and the methods that do the main work of your plug-in. One way this can be achieved is by putting your code to display and collect data from a GUI in its own method that is called from execute. Here is an example:
public boolean execute(PlugInContext context)
{
this.showGUI();
boolean workDoneSuccessfully = this.doWork();
return workDoneSuccessfully;
}
I hope to write more on this blog about the TaskMonitorManager class, TaskWrapper class, and threads in OJ as I learn more about them.
The Sunburned Surveyor
Posts
