Community
Participate
Working Groups
Some clean up is required to reorganize the modelQuery extension points to make them easier to use.
In the past we've utilized some rather ugly tricks to extend the schema driven guided editing. I've recently done some work to clean up this extension mechanism an implement it as an ‘experimental’ extension point that may be useful to other plugin developers that need to provide similar capabilities. We currently make use of this extension for editing WSDL and XML Schema files in order to provide additional ‘possible values’ for attributes and to provide some filtering to constrain spurious suggestions where ‘any elements’ occur. I’ll try to explain how this works. Of course this extension point should be considered purely experimental! In the xml.core plugin the ModelQuery is used to ask grammar related questions about a DOM (e.g. what can go here, what values can this attribute have etc). The ModelQuery extensions can be used to augment the behaviour of the ModelQuery in order to capture additional constraints of your language that can’t be captured in a static XML Schema or DTD grammar. Here’s a snippet of plugin.xml where I’ve specified a modelQueryExtension. Note that an optional namespace attribute can also be specified in order to further refine where your extension is applicable. <!-- this extension point is used to augment the ModelQuery to provide schema specific guided editing --> <extension point="org.eclipse.wst.xml.core.modelQueryExtensions"> <modelQueryExtension class="org.eclipse.wst.xsd.ui.internal.text.XSDModelQueryExtension" contentType="org.eclipse.wst.xsd.contentmodel.xsdsource"> </modelQueryExtension> </extension> The ‘class’ specified by the plugin.xml needs to subclass the abstract ModelQueryExtension class. It can then override one or more of the methods shown below. public abstract class ModelQueryExtension { // this method is used to provide possible values for an attribute // usually this is used to constrain an ‘xsd:string’ type to provide // a dynamic list of possible values // public String[] getAttributeValues(Element ownerElement, String namespace, String name) // this method is used to provide possible values for an element’s text // usually this is used to constrain an ‘xsd:string’ type to provide // a dynamic list of possible values // public String[] getElementValues(Node parentNode, String namespace, String name) // this method is used to filter child elements, this can be used to add //additional constraints when an elements content model is described with //‘wild cards (i.e. ‘xsd:any’) public boolean isApplicableChildElement(Node parentNode, String namespace, } NOTE: At the time of this posting this code hasn’t been released yet so you’ll need to grab the latest xml.core plugin from HEAD (and perhaps the xml.ui plugin to use an example) in order to play with this.
I've cleaned up our WSDL and XMLSchema editors to use this extension point. I suspect some work will be required in the future to make this extension point fit in with more 'ui specific' extension points (such as a content assist extension point). That may mean this extension point will 'morph' into something significantly different in the future. Now that the ModelQuery extension related code is cleaned up, the WSDL and XML Schema editors are better positioned for any such future changes.
mass closing verified bugs I own
