In my work with the TaskFrame class I believe I have discovered a reason to refactor the TaskFrame.setTask(Task argTask) method.
The implementation of the TaskFrame.setTask method currently throws an IllegalStateException if the Task has already been set on the TaskFrame. It seems that setting the Task object displayed by a TaskFrame should only be a "one-time" operation, as indicated by the implementation. I think we could avoid potential bugs if we only allow the Task to be set in the constructor of the TaskFrame class, and remove the setter method altogether. The only reference that I could find for the TaskFrame.setTask method was in the WorkbenchFrame class. The WorkbenchFrame.addTaskFrame method uses the setTask method if a ComponentFactory is available to create TaskFrames. The TaskFrame is created with the ComponentFactory and is then the Task is set in the newly created TaskFrame. The method basically works like this: See if a ComponentFactory is available for the WorkbenchFrame to use in creating the TaskFrame to be added. If there is a ComponentFactory available, use it to create a TaskFrame object and call it's setTask method. If there isn't a ComponentFactory available for creation of the TaskFrame, just use the TaskFrame constructor passing the Task as an argument. I believe that Paul set this system up to support creation of custom TaskFrames using the Factory. The setTask method is necessary, because the ComponentFactory class could be used to create any component, including ones that have nothing to do with a Task. This means its constructor does not accept a Task object as a parameter. As a result, if the ComponentFactory is used, the Task has to be set after object construction. I have no objections to this system, but I would like to modify it slightly to [1] remove the setTask method from the TaskFrame class, and [2] to better enable support of custom TaskFrames. Let's provide a default implementation of ComponentFactory that is made specifically for TaskFrames. We'll call it TaskFrameFactory. In the TaskFrameFactory will add two (2) methods. The first method, TaskFrameFactory.setNextTask, will be used to set the task that will be next in line for wrapping in a TaskFrame. The second method, setNextTaskFrameType, will accept a String indicating the type of TaskFrame that should be created yet. The Workbench.addTaskFrame method would then look something like this: public TaskFrame addTaskFrame(Task argTask) { // Place holder for the TaskFrame that we are about to create and add to the WorkbenchFrame. TaskFrame toReturn; if (taskFrameFactory != null) { IllegalStateException toThrow = new IllegalStateException("No TaskFrameFactory set in WorkbenchFrame. Task creation failed."); this.handleThrowable(toThrow); } else { this.taskFrameFactory.setNextTask(argTask); this.taskFrameFactory.setNextTaskFrameType("Default Task Frame"); toReturn = taskFrameFactory.createComponent(); } return toReturn; } This would allow us to continue using the Factory pattern to create TaskFrame objects, but would allow us to remove the setTask method and would also support creation of custom TaskFrames identified by a String at runtime. Are there any objections to this? I can code the modifications I recommended here as part of my other work on the TaskFrame class. The Sunburned Surveyor P.S. - Would anyone have an objection to creating a branch in the SVN for these modifications. If I get all the kinks ironed out and everyone approves I can then use this branch for my upcoming work on the next official release. If this is a problem, or these changes are controversial, I will keep the changes in the SurveyOS SVN. ------------------------------------------------------------------------- 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