Applications and Documents

The following diagram illustrates the static structure of the application framework. The central inferface is the Application, which contains a set of Documents and a set of Actions. The application displays itself in an AppContext.

An application is a class that implements the Application interface, and this package provides an abstract class that implements some of this interface. For example, a graph editor would subclass AbstractApplication as, say, GraphEditor. The application is the class that contains the main method, and is responsible for creating and initializing all other classes. In particular, it is responsible for initializing the menubars to contain all menus and menu entries (there are no default menus -- it might seem like a good idea, but it isn't).

Although the concrete Application subclasses are responsible for creating the menus, there are a number of actions that are shared by many application, which are provided for convenience in the DefaultActions class. This class is a collection of factory methods that create Swing Action objects, such as Open, Close, Save, and so on.

Each Application contains a list of currently-open Documents, one of which is designated as the current document. The Document interface captures the abstraction of a document which can be opened, editied, and (probably) written to the file system. Each document may or may not contain a primary file, which is what you would think of for simple documents such as text documents. (More complex document classes may choose to store themselves in multiple files -- or far that matter, somewhere other than in files.) The Document subclass provides the right abstraction that allows us to open and close these documents. In the future, this interface could be extended to allow searching and indexing as well.