Storage Policies

A StoragePolicy captures the notion of how an application deals with persistent storage. This diagram shows the static structure of storage policies.

For example, suppose a user selects the Close entry on a menu. The application typically needs to check whether the document has been edited, and if so, it needs to decide what to do about it. This logic is implemented by a storage policy. In general, the storage policy is not responsible for turning a document into a file on the file system, the document does that. The storage policy is responsible, however, for ensuring that the document has a file to be saved to, that the user can't accidently close the file without saving it, and so forth.

BasicStoragePolicy is just about the simplest possible implementation of a storage policy. It doesn't really do anything interesting, or useful.

DefaultStoragePolicy is a more useful storage policy implementation for applications that use files on the local file system. It contains two file choosers, one for saving files and one for loading files. The context of each file chooser is maintained over the lifetime of the storage policy, so that you never start off in the same directory over and over again. The open method uses the document factory of the application to create a document for a given file, possibly allowing the user to browse for the file if the application did not specify it. The saveAs method uses the save file chooser to choose a filename for the new file. The save method saves the file if the document was already associated with a file, or defers to saveAs if no document had previously been specified. The close method prevents the user from closing the file without saving, if the document had been modified. Unfortunately due to the design of JFileChooser, it is useless for browsing files specified using a URL. We are looking at ways of extending the StoragePolicy mechanism to include such documents.

We are interested in writing more intelligent storage policies that are capable of operating with less interaction from the user. (Do YOU like all those stupid confirmation popups?) One thing to try would be a storage policy that always implicitly saves the current version of the document. It is likely that such a storage policy would be useful only with an infinite undo mechanism and some way of visualizing the current state of the Document.