wxDocview vs. wxWidgets
If you are familiar with wxWidget you may have recognized that this portable GUI toolkit also delivers a document/ view framework in its standard distribution. So, why another document/ view framework?
Motivation
The reason to develop this framework was that the wxWidget doc/view architecture is heavily related to the interface you want to use for your application (i.e. MDI or SDI). Views are responsible for creating the windows and frames that they use for displaying document data. This makes views only useable for the one type of application.
If you develop a MDI application your views rely on the MDI classes and you will have to do a lot of work if you want switch to another interface, i.e. SDI, because the views are related to a wxDocMDIChildFrame, for example. Therefore you can not write general view classes that can be used in any type of application.
Imagine someone has written a nice viewing class to display the content of an HTML document. Of course one would like to make this viewing class part of a library that includes the HTML document class, plus its viewing classes. The trouble in that case is that the view class creates a window and frame for one type of application, this makes it impossible to use it in another type of application.
Alternative Approach
This framework has another approach: A view is independent from a frame, it is only interested in one window, which it will use for displaying data from a document. Where this window is situated in the application is not important for the view. A view knows nothing about the user interface, it may be MDI, SDI etc.. You can use a view with several user interfaces; the view is connected to a specific interface (window or frame) at runtime by a view connector. After creation of a new view, a view connector class is used to generate or use an existing window for the view, and if needed, it will also create the (child)frame to be used as parent for the new window. Now a view only needs to know its display window, which it uses for displaying document data, and for sending events up to that window, including parent windows or frames. The view connector is responsible for connecting of a view into the application, and this makes a view application independent.
Because of this a view can easily be used in all types of applications, and therefore be made part of a library. In the wxArt2D library, a view called a2dCanvasView is used to display the content of a a2dCanvasDocument, on a a2dCanvas window. a2dCanvasView is only aware of one window, which is a2dCanvas. It does not know, if the application is SDI or MDI, or any other. This way of connecting views works very well when reusing the same windows in one frame for displaying several document plus views. All that is needed is to disconnect the old views from the windows in a frame and connect the new ones.
Benefits
The wxDocview framework is an improvement over the wxWidgets Docview classes for the following reasons:
- View connectors make a view independent from a window. The view connector associates a window with a view. This was the biggest stumbling block with the wxWidgets version, and which made it unsuitable for use as a base for wxArt2D, where view and rendering are combined in one class and capable of being plugged into a a2dCanvas. Views are not responsible for windows, and in fact views can be plugged in an out of its display window. Moreover, it can have a document from which it can display information, however, this is not a must.
- Combining several views into one frame is easy. A view may or may not have a document attached, so a set of Views can remain attached to a window, and its parent, even if the documents are all closed. On opening a new document all of the existing views can be reused for displaying a view of the new document. In the wxWidgets version this is close to impossible.
- Documents do not own views, and do not have a list of views, thus making many things much easier. For example, a view can display information from several documents. The Event Distributor is the key to this by accepting events from a Document and dispatching them to Views and other registered classes. Thus it is possible for a view to claim an event and update its view of the associated document.
- Almost everything works via events, and in many cases special events are sent to a global event distributor which dispatches the events to those handler classes registered to it. In this way your application is always in complete synchronization, something that is not possible in the wxWidgets version.
- The concept of a document manager, is replaced by the Command Processor. This class, in addition to doing what the old docmanager did, adds a central Command Processor to the application. The Command Processor maintains documents and templates, and manages the view for the current document. Command processing is implemented in such a way as to make macro recording much easier. The Command Processor commands are implemented as ascii strings. Internal there is a variable list, which can be used as part of commands. Commands can set and use variables, either set by the application or by external commands.
- Important is the way document and their view and windows are closed. A view can be closed for two reasons. One when its frame/window is closed, two when a/its document is closed. So two paths. The second path does come to the view via its document via a viewclose event, and it may/sometimes should also close the windows that contains the view. In a multi frame app this is the case. In a single frame having several views, the windows should stay intact, and maybe even the view, and only the document should be decoupled from its document. In that case the views can be used for a new document later on. In the first path (closing the frame), the close event comes form the window, and is sent to the view, and closing the view might lead to also needing to close the document it displays. This is above situation is arranged in the wxArt2D version in an orderly manner, without confusion.
- There are two templates on to link file extension to document types and an IO handler class to read such a file into a document. A second template is used to couple document types to view types. This is different form the original docview classes where there was only one template, which coupled file extension plus document type plus viewtype in one. In many cases that does not make sense.
- IO handlers are the classes to read files into document, a basic XML pull/push parser iohandler is part of the docview classes. This makes it easy to read and write XML based data to and from into an internal document.