jmdiframework and the Document-View paradigm

Note: The Java MDI application framework was designed with the ideas of the Document-View paradigm in mind. However, that does not mean that this framework forces you to adhere to a particular paradigm. If you want, you can, for example, add your GUI component to your DocumentData object, therefore violating the division between document data and document view. It's up to you to find and implement the method which fits your needs best.

Graphical overview

Splitting Documents in data and views

Which part is responsible for what tasks?

DocumentData:
Stores the information contained in a document, and maintains a log of all previously applied actions which enable the DocumentData object to perform undo and redo operations.
DocumentView:
Knows how to visualize the data and processes user input. Furthermore, the DocumentView is resposible for clipboard transfer actions (cut, copy, paste) because they can be treated somehow like user interactions.

In theory, it's really obvious how to split data and view. Just look at the diagram below:

The problem with the division between data and view is that usually the view already contains the data in some way, otherwise it simply couldn't display it on the screen. An ordinary text editor is a good example for this problem. The data could be seen as a simple String object, however, the view (perhaps a JTextArea) already contains the data and makes it accessible via the getText() method. This redundancy leads to a synchronization problem, which is covered in the next section.

Interaction between data, view and actions

A major difficulty of the Document-View paradigm is keeping view and data synchronized. Therefore, we need to implement a means of bi-directional communication between data and view. There are two situations where this means of communication is used:

The view detects some user input which was intended to modify the document's data. The view is usually capable of graphically reflecting the changes to the user immediately, but the data still contains obsolete information and has to be informed about the user input. This is done by creating a new Action which corresponds to the user input and calling the data's applyAction() method.
Example:
```
Action myAction = new SomeAction(...);
getDocument().getData().applyAction(myAction);
```
This applies the action to the DocumentData's information and records this action in the action log, so that it can be undone at a later time.
The DocumentData's information have changed, and the view needs to be updated. This situation is usually less common than the first one, but still it's the case after undo or redo operations took place or after a document has been loaded. The DocumentData object calls updateView(), which is usually just a convenience method for calling getDocument().getView().dataUpdated(). When the view's dataUpdated() method is called, it should react by redrawing and updating itself according to the new information of the document's data.

Instantiation sequence

When overwriting the default constructors of DocumentView, DocumentData or DocumentWindow classes, it's important to know which of the other elements have already been created. The usual creation sequence is:

Document
DocumentData
DocumentView
DocumentWindow

That means that you can assume that the DocumentData object already exists while the DocumentView's constructor is executed and you can safely access it using getDocument().getData(). It won't work the other way round: trying to get the DocumentView in the DocumentData constructor would result in a NullPointerException.