The exemplar model has been around since the dawn of Smallworld and its single task is to serve as the base class for dialogs. When frameworks arrived in release 3.2, also a component named plugin was introduced. The plugin serves as plug in a framework were it holds actions, dialogs and toolbars which can be used by the framework.
The plugin also has a method build_gui() that allows you to create an embedded dialog. And indeed many plugins build gui’s in this method. But wait a minute: wasn’t that the job of my old friend model? I like the design principle Separation of Concerns and I think plugin has taken on one to many concern.
A clean separation of plugin and model forces the GUI development to be made independent of its environment, independent of the position of the model in the application architecture. That dependency on the position is taken care of by the plugin. That means, for example, that exactly the same model can be used in an editor_plugin and in the explorer.
As an example I have created a dialog (supply_point_model) that shows the feeding substation for a supply_point and allows you to highlight the path to it. I have inserted the same model 4 times in the application: as a standalone dialog, as an embedded dialog, as an editor plugin for an object_editor and as a plugin for the explorer. The software architecture looks something like this:
The resulting GUI looks like this:
Exactly the same dialog is used in 4 places.
The supply_point, the target of the dialog, is selected differently in each plugin. The explorer plugin uses the selection in the explorer list, the dialog plugin uses the selection in the map and the editor plugin uses the current object in the editor. But for the dialog that makes no difference, the dialog is the same.
I have attached the sourcecode, should this example trigger your curiosity.