Extension points for the designer #33
Description
pmd/pmd#2118 introduces a mechanism to add extension points for the designer.
Goal
Let language implementations provide language-specific insights to the designer without needing the designer to know about them
Mechanism
Adding an extension point
- Publish an interface in pmd-core. The interface should be the smallest possible, different interfaces should be used for orthogonal services
- Add it to
DesignerBindings, which is provided by a LanguageVersionHandler - Implement the feature in the designer by using instances of the interface provided by the language modules
Implementing an extension point
- Implement the interface somewhere
- Return an instance of it in the correct method of the DesignerBindings for the language
Candidates for being extension points
- Usage highlight ([core] Add designer bindings interface pmd#2118)
- XPath functions (currently typeIs is hard-coded for java, and accessed through reflection)
- Logic for describing a node in the treeview (currently
getImage, this will be deprecated in 7.0) - Listing the available node names for XPath completion. Currently looks into the AST package, this is not appropriate for some languages (XML, or Swift in the antlr impl, because node classes are nested in the parser class)
- Syntax highlighters. This is not trivial and needs pmd-core to publish an API to represent "colors", or css classes. Some points that jump to mind:
- The highlighters have a small dependency on the code area library, which shouldn't be a dependency of pmd-core
- The highlighters rely on Java 8 so this is anyway out of the question until 7.0 unless someone wants to rewrite them
- How does this interact with css, and will we still be able to use it?
Non-candidates
- The scopes view. Doing that would require an API in pmd-core to represent tree items somehow, and it feels like too much work for something that ultimately should be internal to the language implementation. I think it should be removed entirely at some point.