MVC Workbench is a platform that hosts MVC components. An MVC component is a simple application that realizes the Model-View-Controller architecture. Thus, an MVC component can be just about any application. Examples of MVC components include basic spread sheets, editors, database browsers, calculators, etc.
An MVC component contains the following subcomponents: a model that provides application-specific data and logic, one or more views of the model, one or more controllers to interpret user commands, and one or more menus containing user commands.
The MVC Workbench allows users to load and run MVC components. Several MVC components could be running at the same time. Thus, an instance of MVC Workbench loaded with MVC components for word processors and spreadsheets would appear to the user as a virtual office, while an instance of MVC Workbench loaded with MVC components for compilers and debuggers would appear to the user as a loosely integrated development environment.
MVC Workbench simplifies the task of MVC component developers because common functionality such as saving, loading, and viewing models is provided the workbench. (Is it possible that the workbench can also provide a generic controller?)
Remember: the success of a framework or workbench is determined by how easy it is for third parties to create useful components.
A component consists of several .class files. One contains the component's model class, several may contain view classes, and several may contain controller classes. A component may also contain a descriptor file that associates the model, views, and controllers to the correct files. All of these files may be bundled together into a .jar file for user convenience. Furthermore, the component may be deployed in a specific directory.
Here's the main scenario for loading a component:
User: Selects Component/Load
WB: Prompts user for the location of the component
User: Specifies location
WB: Loads component
After a component is loaded, the component's command menus should appear on the menu bar of the desktop. In addition, the model name should appear in the view menu. Selecting this item should pop up a menu of the different types of views available for this model. The file menu should allow the user to open, close and create new models for this component.
Removing a component undoes all of the changes made by loading the component. Removing a component might be done to recover space on the menu bar.
This might be needed if some menu items should be disabled in case they don't apply to the current model. Selecting a model might simply entail selecting an open view of the component's model.
This use case includes any special steps component developers may need to follow in order to get WorkBench to recognize their components.
Ideally, Workbench should allow multiple models to be open for editing at the same time. If this leads to complications, it is allowable to make a rule that only one model can be open for editing. We shall assume this is the case in the following elaborations.
User: selects File/Load
WB: Prompt's user to save changes in the current model if it has been changed
since the last time it was saved.
User: clicks chooses to save the current model
WB: Saves current model
WB: Prompt's user for the name of the file containing the model to be loaded.
User: Selects file.
WB: Loads the file, making its contents the new current model.
Note: If the model being loaded was created by a component that is not loaded, then there are two options. Ideally, WB should infer the needed component and load it. Less ideal: WB should refuse to load the model. In either case it should be clear which component created the model.
New models can only be created if the corresponding component has already been loaded.
User: Selects File/New/Model Type
WB: Prompt's user to save changes in the current model if it has been changed
since the last time it was saved.
User: clicks chooses to save the current model
WB: Saves current model
WB: Creates a new instance of the selected model type
User: Selects File/Save
WB: If this is a first save or save as, the user is prompted for the name of a
file
WB: Writes model to the file.
User: Selects View/Model Type/View Type
WB: Creates and displays a new instance of the selected view type
A component is a class that implements the MVCCompomnent interface. Here's a rough sketch:
interface MVCComponent {
�� String getName();
�� Class getModelClass();
�� Set<Class> getViewClasses();
�� Set<JMenu> getMenus(); // command
menus
}
The base class of all models might be a simple modification of the one
given in the framework package:
http://www.cs.sjsu.edu/faculty/pearce/jutil/framework/Model.java
Views will live inside of JInternalFrames:
abstract class View extends JPanel
�� implements ActionListener, Observer {
�� abstract Model getModel();
�� // etc.
}
For more details see:
http://www.cs.sjsu.edu/faculty/pearce/jutil/framework/AppView.java
and
http://www.cs.sjsu.edu/faculty/pearce/j2se/multiview.htm
The Workbench itself instantiates the MVC Pattern, although perhaps there is no need for a view:
I moved an updated and more complete discussion of the implementation to implementation.htm.
At least the model class should be accompanied by a JUnit test suite.
There are several possibilities for deploying components. One idea is to deploy components as .jar files in a special directory.
Each team will present a progress report according to the following schedule
http://www.cs.sjsu.edu/faculty/pearce/schedules/sp07.htm
For session guidelines see:
http://www.cs.sjsu.edu/faculty/pearce/cs160/Guidelines.htm
Note that finished projects are due the last week of class.
In addition, each student should submit a report on the component he or she developed for the workbench.
For details and additional requirements click here.
The team as a whole will develop the MVCWorkbench. To demonstrate the ease of customizing the workbench, each individual team member will develop a component for the workbench. Team members are free to suggest components. Here are a few of my suggestions:
It might also be useful to create a simple test component (such as a bank account) during the development of the workbench.
Other suggested components: Game of Life, Logic Circuit Modeler