Of models and plugins

Models & Plugins

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.


Service Provider

In Smallworld 4.2(?) a concept of Service Providers was introduced. This gives you the benefit of not needing to know the name of another plugin you need access to. Even though there would be some thought about communicating this across the databus and having the appropriate plugin handle it, but that is another conversation.

All you need to do is call appl.get_service_provider(:map_manager) and it returns the map manager no matter what the name is. To get a list of service providers look at this page.

To add your plugin as a service provider, you need to add :service_provider to your plugin's databus_producer_data_types constant. Second, your plugin needs to respond to sw_databus_data_requested(:service_provider,:provider_name) and return the initialized plugin (_self) if the provider name is what you are expecting.

Re-register Plug-in

During development you may need to add/remove a databus consumer or producer settings on a plugin. You can call the following after you load the changes to databus_[producer|consumer]_data_types on the plugin.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License