>In Part II, I introduced the new org.eclipse.wst.xsl.ui.contentAssistProcessor extension point. Which allows adopters to contribute their own content assistance to the XSLT Editor. How does one implement this, and what classes are available to make this easier to implement?
With the new extension point, the existing XSL Content assistance processor has been migrated to use the extension point. So we’ll take a look at the classes involved.
With the refactoring that has occured, a new public package has been created, org.eclipse.wst.xsl.ui.provisional.contentassist. This package contains the AbstractXSLContentAssistProcessor class which adopters can extend to implement their own IContentAssistProcessors. It is this implementation that is used by the extension point. It must implement the jface text IContentAssistProcessor interface.
The AbstractXSLContentAssistProcessor class provides several convience methods that adopters may need when they implement their own processor. These items include methods for getting the current node at the cursor position, initializing common proposal variables, and retrieving attribute information. Adopters will need to implement the computeProposals method.
This class provides common functionality for the actual Request for Proposals implement. XSL Tools has refactored much of the XSL element and attribute specific requests into their own classes and uses a Factory pattern to return the correct class that provides the proposals. This helps isolate changes, and makes testing of new functionality and bug fixes much easier.
A class that is used to build a Proposal on the fly. Pass in the appropriate information, and it will construct a proposal with all the necessary information that needs to be used by the editor.
Implements the Null Object Pattern so that NULLs do not have to be passed back when proposals do not exist.
SelectAttributeContentAssistRequest and TestAttributeContentAssistRequest:
There are many times when implementations need to add proposals to select and test attributes. These two classes are used by the existing XSLT Editor, but can be extended by adopters to provide additional functionality or override functionality to add their proposals to the list. Both of these extend the AbstractContentAssistRequest class mentioned earlier.
For complete examples on how these classes are used, or could be used, take a look at the org.eclipse.wst.xsl.ui.internal.contentassist.XSLContentAssistProcessor implementation. Also feel free to provide comments and suggestions for enhancements on bug 259721.
Adopters do not have to use these classes if they do not want, but they do help make implementation a bit easier.