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

Reply via email to