Community
Participate
Working Groups
XSL Tools needs an extension point mechanism for adopters to easily add additional content assistance or customization of the content assistance that exists. JDT provides this through their proposals extension point, and is able to allow the user to enable and disable proposals. This will allow easier customization of the editor where needed. The extension point should probably be version aware so that the proposals can be limited to particular versions of XML. An example of a possible extension would be for EXSLT functionality for XSLT 1.0.
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
migrating prior 3.1 enhancements for future for further triage and planning.
Assigning inbox items to triaged since these have all be triaged.
Created attachment 147744 [details] XSL Content Assist Processor Extension This migrates the existing XSL Content Assistance to an extension point. This allows other XSL Content Assistance processors to be contributed.
Created attachment 147753 [details] Working Content Assistance with Unit Tests for Extension Point
Adding Paul Glezen as this extension point may be of use in addition to work that will happen on bug 289498.
Lately I've been using XPath Templates to provide poor-man's content assist. It works pretty well in many cases. But one area where a plug-in would help is establishing the additional context for content assist. For example, the XPath templates know when I'm inside a "select" attribute of a "variable" tag. So it's active there. But it doesn't know when I'm in an attribute of a custom extension element that accepts XPath expressions. For that, the XPath templates are inactive. But a plug-in with knowledge of which extended attributes accept XPath expressions could remedy this.
(In reply to comment #7) > Lately I've been using XPath Templates to provide poor-man's content assist. > It works pretty well in many cases. But one area where a plug-in would help is > establishing the additional context for content assist. For example, the XPath > templates know when I'm inside a "select" attribute of a "variable" tag. So > it's active there. But it doesn't know when I'm in an attribute of a custom > extension element that accepts XPath expressions. For that, the XPath > templates are inactive. > > But a plug-in with knowledge of which extended attributes accept XPath > expressions could remedy this. Correct. I'll have an example additional XSLT XPath contributions. I'll be adding an EXSLT implementation that can be used as a guide for adding additional XPath functions that are context aware a bit. But for now the Templates approach is the way to go, until we get the extension points in place.
Code for this has been checked in. Will leave this open for a bit, to allow time for adopters to provide some feedback. All existing and new unit tests pass in the build, and have been released to the build system.
Updated SDK documentation to include the new extension point. Code seems to be working, and EXSLT example is included. See bug 243579 for more information on that contribution status.
