As said earlier, earch editing view in MlView implements the MlViewIView interface. When the user opens an existing document or creates a new document, a new editing view is instanciated. That view is then "associated" to the instance of MlViewXMLDocument that represent the document. The editing view is responsible of providing a graphical interface to the user so that she chan edit the instance of MlViewXMLDocument. Of course, they can be several instances of MlViewIView in the editor at the same time. Each instance of MlViewIView is then rendered in a tab. When the user clicks on a tab, the MlViewIView contained in that tab becomes the current active view.
Once the MlViewIView is instanciated, the editor calls the MlViewIView::connect_to_doc() method to "connect" the view to the instance of MlViewXMLDocument it is associated to. This connection allows the view to listen to event emited by the MlViewXMLDocument to reflect its state. Basically, whenever an editing action is performed on the MlViewXMLDocument, it emits events to reflect its state, to say "hey folks, something has changed here". Views that are connected to these events can then update themselves so that the user can see what happens to the document graphically. Logically, when the user closes a view, the instance of MlViewIView that represents the view is destroyed and before the destruction, the MlViewIView::disconnect_from_doc() is called do "disconnect" the view from the instance of MlViewXMLDocument it is associated to.
Another important feature in the views management is the "editing actions export" feature. In MlView, again, editing views are the components that know what kind of editing action can be done on a document. Let me explain that a bit. A tree oriented editing view easily allows editing actions like cutting a subtree out of the document without any risk to let the document in a not well formed state. This editing action is much more complicated to achieve in a text oriented editing view where the document is presented as a sequence of characters. In short, each type of editing view allows some specific kind of editing action. That being said, in MlView, editing views tell the editor what kind of editing action they support. This allows the editor to support several type of editing view in the same application. Today, this "editing actions export" feature is visible during two workflows:
user right clicks on the editing editing view. When the user right clicks in an editing view, she expects a contextual menu to popup. In MlView, it is the view that is responsible of building the contextual menu. Not the editor. The editor knows nothing about what is happening at the view level. When a widget, part of an editing detects a right clicks, it lets the application context emit a "contextual-menu-request" event. Editing views in the editors listen to that event. When a view receives that event, it can know if that event has been fired by one of its widgets. If yes, it then build a contextual menu and pops it up.
user clicks on the "edit" menu of the editor's main menubar. When the user clicks on the "Edit" menu of the editor's main menubar, the menu should contain menuitems that let her perform some editing actions on the document. These editing actions are sometimes contextual e.g if the currently selected node is the document root node, the edit menu should not propose to cut it. Therefore, when the user clicks on the "Edit" menu, the editor makes the view emit the event "application-menu-populating-requested". The view can then by default build the part of the "Edit" menu that it is responsible of, merge that submenu with the content of the "Edit" menu.