V
VisionSet
Briefly I have a controller that instantiates swing models and the view.
The models are registered with the view, and further event driven updates
are handled by swings internal event mechanism.
The view has inner action classes that generally call the controller which
initiates business processes. All standard stuff hopefully.
Now in more detail.
I have Swing models (eg ComboBoxModel, TableModel) that I have implemented
as separate classes, extending AbstractTableModel for example. These are
instantiated by the controller at startup and passed to the view which does
eg myJTable.setModel(myTableModel).
When an Action is triggered the views inner Action class calls the
controller via a controller interface - decoupling controller and view.
The controller then calls one of its TaskControllers which creates a new
inner Task instance that threads a new long business process (network call)
and then updates the GUI on the event thread.
My Controller acts as Mediator? for View, Swing Models, and the
TaskControllers.
The abstract Task class is similar to Suns SwingWorker class. It has two
abstract methods one runs in a new thread and does the long task, the other
is called at the end of the former but runs on the event thread to update
the GUI (by updating the model).
Originally my Controller was full of innerclass subclasses of Task.
So I factored them out into there own top level classes.
The controller creates an instance of a TaskManager at startup which has
attribute such as SwingModels and the main Controller.
When the controller decides to perform a business process it calls the task
manager to do the task, the task manager has an inner Task subclass and one
of these is instantiated each time the business process is required.
I was trying to get away from inner classes, but it seems they perfect here,
I didn't think it was a good idea to keep passing parameters where the
reference is known to be unchanging.
Therefore the TaskManager class is there soley to encapsulate the initial
controller attributes relevent to the task it manages.
Am I making any sense or do you want a link to UML?
If all that is understandable, is it a sensible design?
class Controller {
TableModel aSwingModel;
TaskManager tm;
Controller() {
tm = new TaskManager(aSwingModel);
}
void doTask {
tm.doTask();
}
}
class TaskManager {
TableModel aSwingModel;
doTask() {
new Taskette();
}
private class Taskette extends Task {
// change and update aSwingModel
}
}
The models are registered with the view, and further event driven updates
are handled by swings internal event mechanism.
The view has inner action classes that generally call the controller which
initiates business processes. All standard stuff hopefully.
Now in more detail.
I have Swing models (eg ComboBoxModel, TableModel) that I have implemented
as separate classes, extending AbstractTableModel for example. These are
instantiated by the controller at startup and passed to the view which does
eg myJTable.setModel(myTableModel).
When an Action is triggered the views inner Action class calls the
controller via a controller interface - decoupling controller and view.
The controller then calls one of its TaskControllers which creates a new
inner Task instance that threads a new long business process (network call)
and then updates the GUI on the event thread.
My Controller acts as Mediator? for View, Swing Models, and the
TaskControllers.
The abstract Task class is similar to Suns SwingWorker class. It has two
abstract methods one runs in a new thread and does the long task, the other
is called at the end of the former but runs on the event thread to update
the GUI (by updating the model).
Originally my Controller was full of innerclass subclasses of Task.
So I factored them out into there own top level classes.
The controller creates an instance of a TaskManager at startup which has
attribute such as SwingModels and the main Controller.
When the controller decides to perform a business process it calls the task
manager to do the task, the task manager has an inner Task subclass and one
of these is instantiated each time the business process is required.
I was trying to get away from inner classes, but it seems they perfect here,
I didn't think it was a good idea to keep passing parameters where the
reference is known to be unchanging.
Therefore the TaskManager class is there soley to encapsulate the initial
controller attributes relevent to the task it manages.
Am I making any sense or do you want a link to UML?
If all that is understandable, is it a sensible design?
class Controller {
TableModel aSwingModel;
TaskManager tm;
Controller() {
tm = new TaskManager(aSwingModel);
}
void doTask {
tm.doTask();
}
}
class TaskManager {
TableModel aSwingModel;
doTask() {
new Taskette();
}
private class Taskette extends Task {
// change and update aSwingModel
}
}