Managing Workspaces

[dloy]

I'd like to solicit comments on a good design pattern for managing workspaces. Here are the brief requirements:

1. a Workspace is defined as the set of frames, views and documents that the user had last opened on the MDI application.

2. a Workspace is serialized to a file.

3. [this may be a separate issue] individual documents are stored within the workspace file.


This should be easier to do with an MVC architecture (eg, serialize the controller, which then serializes the view and associated model). It appears a little tricky in doc/view architecture. I assume we have these subclasses upon which everything else is based on:

1. CMDocument, CMView and CMChildFrame. All three of these are serializable. CMDocument contains a unique document ID (unique within the workspace).

2. CMWorkspace contains a map of document IDs to CMDocViewStore objects.

3. CMDocViewStore contains three CMemFile objects, one each to serialize CMDocument, CMView and CMChildFrame.

4. CMWorkspace has three overloaded methods Serialize(CMDocument/CMView/CMChildFrame, BOOL storing/loading).
A call to that will traverse the doc/view lineage to get the document ID, retrieve the appropriate CMDocViewStore, and serialize the doc, view or frame to the right CMemFile.

5. When you serialize the CMWorkspace, the map of CMDocViewStore gets serialized as well.



Open Workspace will produce the following:

<PRE>
for all document IDs in CMWorkspace,
call CWinApp::OpenDocumentFile(docID)
...
CDocTemplate::CreateNewDocument()
// CMDocument's name set to the docID
CDocTemplate::CreateNewFrame()
CMChildFrame created
GetActiveWorkspace()->Serialize(this, LOAD)
// above call sets the serialized x, y,
// width and height and state of the child
// window on the MDI workspace.
CMView::OnCreate()
GetActiveWorkspace()->Serialize(this, LOAD)
// I assume CMWorkspace will be able to
// retrieve the doc ID from the view at this
// point?
CMDocument::OnOpenDocument()
CDocument::DeleteContents()
GetActiveWorkspace()->Serialize(this, LOAD)
... etc..
</PRE>

My only concern with this design is that it's hard to make a 'generic' workspace manager. eg, you'll have to subclass CMDocument, CMView and CMChildFrame. Also, I'm not sure if multiple views -> one document will work that well here. Currently that will never happen in this project, but I'd like to reuse as many components as possible for the corporate library.

Can anyone see any problems with this design?

Thanks