Storing plugin settings
Plugin settings are part of the Shared Access Layer (SAL) component of the Atlassian plugin framework. Plugin settings provide a cross-product mechanism for persisting values relied upon by plugins.
PluginSettings objects are created with a
PluginSettingsFactory, like this:
PluginSettingsFactory interface includes the
createGlobalSettings() method, which returns a
PluginSettings object, as shown in the example.
Behind the scenes, settings are stored in a product-specific way. In a Confluence plugin, the
pluginSettingsFactory will be a
createGlobalSettings() will return a
ConfluencePluginSettings object uses Bandana internally to store the plugin settings. For a JIRA plugin, the
JiraPluginSettings objects that use PropertySets to store the settings.
Here is a diagram of SAL’s plugin settings objects:
PluginSettingsFactory uses the abstract factory pattern: it “provides an interface for creating families of related or dependent objects without specifying their concrete classes” (p. 87 in Design Patterns by Gamma et al).
PluginSettingsFactory allows us to create specific
PluginSettings objects for Confluence, JIRA, and other products depending on what type of
ConfluencePluginSettingsFactory) is in use, which depends on what product a plugin is for.
Plugin developers benefit from the use of the abstract factory pattern here in several ways. No matter what the target product for a plugin, one syntax can be used to interact with plugin settings. So it is not necessary for developers to learn and remember multiple, distinct settings storage syntax for different products. And a particular plugin could potentially have multiple target products without special handling, at least as far as plugin settings are concerned.
These are benefits often seen when using factories for object creation: users of the object are insulated from the specific objects used and their implementations, and maintenance changes only need to occur in one location rather than in each client.