Rate this page:
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.
objects are created with a , like this:
PluginSettings pluginSettings = pluginSettingsFactory.createGlobalSettings();
The interface includes the method, which returns a object, as shown in the example.
Behind the scenes, settings are stored in a product-specific way. In a Confluence plugin, the will be a and will return a object.
Here is a diagram of SAL's plugin settings objects:
The 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).
The allows us to create specific objects for Confluence, JIRA, and other products depending on what type of (e.g. ) 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.
Rate this page: