Dealing with many similar pluginsTable of Contents
Sometimes, you may wish to develop plugins for a series of similar functions. As an example, consider the distribution plots. These generate fairly similar code, and of course it is desirable to make the graphical interfaces look similar to each other. Finally large sections of the help files can be identical. Only a few parameters are different for each plugin.
The naive approach to this is to develop one plugin, then basically copy and paste the entire contents of the .js, .xml, and .rkh files, then changing the few portions that are different. However, what if sometime later you find a spelling mistake that has been copied and pasted to all plugins? What if you want to add support for a new feature? You would have to visit all plugins again, and change each single one. A tiresome and tedious process.
A second approach would be to use embedding. However, in some cases this does not lend itself well to the problem at hand, mostly because the “chunks” you can embed are sometimes too large to be useful, and it places some constraints on the layout. For these cases, the concepts including .js files, including .xml files and snippets can be very useful (but see the thoughts on when it is preferable to use embedding).
One word of caution, before you begin reading, though: These concepts can help making it simpler to deal with many similar plugins, and can improve maintainability and readability of those plugins. However, overdoing it can easily lead to the reverse effect. Use with some caution.