Oxygen XML Author Eclipse plugin includes support for configuring the proposed values that appear in the Content Completion Assistant. To do so, a configuration file is used, along with the associated schema, to add or replace possible values for attributes or elements that are proposed in the Content Completion Assistant.
For an example of a specific use-case, suppose that you want the Content Completion
Assistant to propose several possible values for the language code when you use an
@xml:lang attribute.
If you extend a framework, you need to copy the content of the cc_config.xml file from the base framework and modify it (e.g. create a resources folder in your framework extension folder and place the file there). You also need to make sure that the folder that contains the cc_config.xml file in your extension (e.g. resources) is listed in the Classpath tab before the one from the base framework.
If you only want to make small changes or add extra rules in your custom content completion configuration file, you need to name it cc_config_ext.xml and all the rules inside it are merged with the base cc_config.xml file. The merging is done by taking all the rules specified in the cc_config_ext.xml file into consideration after processing the set of rules from the base cc_config.xml file.
Refresh
(F5) action to test your customizations, without
having to restart the application.valueProposals instructions that will match an element or attribute name
and has the following attributes:path="title" matches all the <title>
elements in the document.path="chapter/title" matches only the
<title> elements that are direct children of the
<chapter> element.path="@xml:lang" matches all the @xml:lang
attributes in the document.path="title/@xml:lang" matches only the
@xml:lang attributes that appear on
<title> elements. The XPath expressions can accept multiple attribute conditions and inside each condition you can use AND/OR boolean operators and parentheses to override the priority.
*[@a and @b or @c and @d]
*[@a and (@b or @c) and @d]<elementProposals> element or on an ancestor element. For
example:<elementProposals xmlns:db5="http://docbook.org/ns/docbook"
path="db5:listitem" insertElements="db5:para" />@editable attribute are:<valueProposals> element through: <item> elements, which are grouped inside an
<items> element.<item> element can have a @listValue
attribute, which can be set to true if you want those items to be part of a
list attribute value (such as attr="item1 item2").<xslt> element that references an XSLT script that gets
executed and must return an <items> element.<items> or <xslt>
elements are specified with the help of the @action attribute, which can
have any of the following values:The values in the configuration file can be specified either directly or
by calling an external XSLT file that will extract data from an external source. An
<xslt> element must be used in this situation.
valueProposals offers more flexibility compared
to the old match element that was marked as
deprecated.<match elementName="lg" elementNS="http://www.oxygenxml.com/ns/samples">
<items action="replace">
<item value="stanza"/>
<item value="refrain"/>
</items>
</match>If you want to specify the values directly, the configuration file should look like this:
<!-- Replaces the values for an element with the local name "lg",
from the given namespace -->
<valueProposals path="x:lg" xmlns:x="http://www.oxygenxml.com/ns/samples">
<items action="replace">
<item value="stanza"/>
<item value="refrain"/>
</items>
</valueProposals>
<!-- Adds two values for an attribute "type", from no namespace -->
<valueProposals path="@type" editable="onlyAllowedItems">
<items>
<item value="stanza"/>
<item value="refrain"/>
</items>
</valueProposals>
The possible values of an attribute depend on the value of another attribute from the same element:
<valueProposals path="property[@name='color']">
<items>
<item value="red"/>
<item value="blue"/>
</items>
</valueProposals>
<valueProposals path="property[@name='shape']">
<items>
<item value="rectangle"/>
<item value="square"/>
</items>
</valueProposals>
If you want to collect values from an external XSLT script, the configuration file should include something like this:
<xslt href="../xsl/get_values_from_db.xsl" useCache="false" action="replace"/>
get_values_from_db.xsl is executed
to extract values from a database.xsl:message as a debugging mechanism. These messages are presented in
the results area at the bottom of the application whenever the Content Completion
Assistant is invoked.@useCache is set to false, then the XSLT will be invoked
any time the proposals are needed. If @useCache is set to
true, then the XSLT is executed once and the obtained proposals are kept in
a cache and returned every time the proposals are requested again. You can use the
Validate action to drop
the cached values and recompute them.A more complex scenario is if you want to choose the possible values to propose, depending on the context of the element where the content completion was invoked.
Suppose that you want to propose certain possible values for one property (for example, color) and other values for another property (for example, shape). If the property represents a color, then the values should represent applicable colors, while if the property represents a shape, then the values should represent applicable shapes. See the following code snippets:
<sampleArticle>
<!-- The possible values for @value should be "red" and "blue" -->
<property name="color" value=""/>
<!-- The possible values for @value should be "square" and "rectangle" -->
<property name="shape" value=""/>
</sampleArticle>The content completion configuration
file:<config xmlns="http://www.oxygenxml.com/ns/ccfilter/config">
<valueProposals path="property/@value">
<xslt href="get_values.xsl" useCache="false" action="replace"/>
</valueProposals>
</config>The stylesheet that defines the possible values based on the context
of the property on which the content completion was
invoked:<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="xs"
version="3.0">
<xsl:param name="documentSystemID" as="xs:string"></xsl:param>
<xsl:param name="contextElementXPathExpression" as="xs:string"></xsl:param>
<xsl:template name="start">
<xsl:apply-templates select="doc($documentSystemID)"/>
</xsl:template>
<xsl:template match="/">
<xsl:variable name="propertyElement" as="element()">
<xsl:evaluate xpath="$contextElementXPathExpression" context-item="./*"/>
</xsl:variable>
<items>
<xsl:if test="$propertyElement/@name = 'color'">
<item value='red'/>
<item value='blue'/>
</xsl:if>
<xsl:if test="$propertyElement/@name = 'shape'">
<item value='rectangle'/>
<item value='square'/>
</xsl:if>
</items>
</xsl:template>
</xsl:stylesheet>The contextElementXPathExpression parameter will be bound to an XPath
expression that identifies the element in the context where the content completion was
invoked.