Custom Settings Groups
As described in Extension Points for Settings, custom Settings can be declared as children of existing parent groups such as . These parent groups are the existing categories of Settings in the IntelliJ Platform-based IDE.
However, suppose the custom Settings are rich enough to require multiple levels? For example, a custom Setting implementation has multiple sub-Settings implementations. Extension Point declarations can create this kind of multilayer Settings hierarchy.
Extension Points for Parent-Child Settings Relationships
There are multiple ways of creating parent-child relationships in groups of Settings: in implementations, or Extension Point declarations. However, there are performance penalties for creating these relationships in implementations because the objects must be instantiated to determine the relationships. This section describes the syntax for declaring more complex parent-child relationships in
There are two ways of declaring parent-child relationships using the
com.intellij.projectConfigurable EP or
com.intellij.applicationConfigurable EP. The first is to use separate EP declarations that are tied together by the value of one attribute. The second method is to use nested declarations.
Parent-Child Settings Using Separate EPs
One way of declaring a parent-child relationship is by using two separate declarations. This form can be used regardless of whether the parent Settings declaration is in the same plugin. If the
id attribute of the parent is known, a plugin can add Settings as a child of that parent.
For example, below are two declarations for project Settings. The first gets added to the
tools group, and the second gets added to the
id of the parent. The
id of the second, child
<projectConfigurable> adds a suffix (
servers) to the
id of the parent.
See the Attributes for Parent-Child Settings EPs section for details about the suffix
Parent-Child Settings Using Nested EPs
A shorthand for the separate declaration approach is using the
configurable property. This approach nests the child's Settings declaration within the
configurable there isn't a
parentId for the child because the nesting implies it. As with using separate EP declarations, formatting restrictions are placed on the child's
id attribute - the suffix (
servers) gets added. See the Attributes for Parent-Child Settings EPs section.
The example below demonstrates a nested
Within the parent
<projectConfigurable> EP declaration above, more
<configurable> declarations could be added as sibling Settings.
Attributes for Parent-Child Settings EPs
There is only one unique attribute when declaring a child Settings EP. The other attributes are the same as discussed in Settings Declaration Attributes.
For the child of a parent, the
id attribute becomes compound:
Compound FQN of implementation based on
Implementations for Parent-Child Settings
Implementations can be based on
ConfigurableProvider or one of their subtypes. For more information about creating Settings implementations, see Implementations for Settings Extension Points.
Configurable Marker Interfaces
Configurable.Composite interface indicates a configurable component has child components. The preferred approach is to specify child components in the EP declaration. Using the
Composite interface incurs the penalty of loading child classes while building the tree of Settings Swing components.