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 com.intellij.projectConfigurable or com.intellij.applicationConfigurable EPs.
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 id.
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 com.intellij.projectConfigurable or com.intellij.applicationConfigurable EP.
When using 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 configurable declaration:
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:
Attribute | Required | Value |
|---|---|---|
| Y | Compound FQN of implementation based on
|
Implementations for Parent-Child Settings
Implementations can be based on Configurable, ConfigurableProvider or one of their subtypes. For more information about creating Settings implementations, see Implementations for Settings Extension Points.
Configurable Marker Interfaces
The 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.