Structured approach to manage priorities returned by IModelEditorBinding.getPriority()
Currently, the implementation of IModelEditorBinding.getPriority()
return arbitrary values. The only rule is “higher values have lower
priority” (quoting the method documentation).
There are several possibilities for a more structured approach:
- Maintain a wiki page that documents which IEditorPart can be opened
in the same multi-page editor.
- Pro: Avoids creation of a file that knows about all editors, and to which all plugins implementing an editor must have a dependency to (see below).
- Con: List is likely to become outdated.
- Create a central class that contains constants will priorities for
all editors
- Pro: Deterministic ordering of editors, cannot get outdated.
- Con: Dependency “kraken”.
- Add constants for priority classes (e.g., very important, important,
normal, low, lowest, deprecated" to
IModelEditorBinding
- Pro: Avoids magic constants without introducing new plugin dependencies; cannot get outdated
- Con: No total ordering, not deterministic:
- Editors that are “not aware of each other”, and that share the same priority, might appear in different orders (problem exists also in current implementation).
- For editors that are provided by the same plugin, the number of priorities might not suffice.
- Possible solution: Add optional methods that determine if an EditPart “isBefore” or “isAfter” another EditPart. Possible problems: Specification might be inconsistent (->use only one of the two methods?), editors “must be aware of each other”.
(from redmine: issue id 3168, created on 2017-11-17, closed on 2018-03-02)