cobigen xmlplugin

Table of Contents

• XML Plug-in
  • Trigger extension
    • Matcher types
    • VariableAssignment types
    • XML input reader
  • Merger extensions

XML Plug-in

The CobiGen XML Plug-in comes with an input reader for xml artifacts, xml related trigger and matchers and provides different merge mechanisms for XML result documents.

Trigger extension

(since cobigen-xmlplugin v2.0.0)

The XML Plug-in provides a trigger for xml related inputs. It accepts xml documents as input (see XML input reader) and provides additional matching and variable assignment mechanisms. The configuration in the context.xml for this trigger looks like this:

• type 'xml'

  Example of a xml trigger definition

  <trigger id="..." type="xml" templateFolder="...">
      ...
  </trigger>

  This trigger type enables xml documents as inputs.

Matcher types

With the trigger you might define matchers, which restrict the input upon specific aspects:

• type 'nodename' → document’s root name matching

  Example of a xml trigger definition with a nodename matcher

  <trigger id="..." type="xml" templateFolder="...">
      <matcher type="nodename" value="\D\w*">
          ...
      </matcher>
  </trigger>

  This trigger will be enabled if the root name of the declaring input document matches the given regular expression (value).

VariableAssignment types

Furthermore, it provides the ability to extract information from each input for further processing in the templates. The values assigned by variable assignments will be made available in template and the destinationPath of context.xml through the namespace variables.<key>. The XML Plug-in currently provides only one mechanism:

• type 'constant' → constant parameter

  <trigger id="..." type="xml" templateFolder="...">
      <matcher type="nodename" value="\D\w*">
          <variableAssignment type="constant" key="domain" value="restaurant" />
      </matcher>
  </trigger>

This variable assignment assigns the value to the key as a constant.

XML input reader

The Cobigen XML Plug-in implements an input reader for parsed xml documents. So API user can pass org.w3c.dom.Document objects for generation. For getting the right parsed xml inputs you can easily use the xmlplugin.util.XmlUtil, which provides static functionality to parse xml files or input streams and get the appropriate Document object.

Template object

Due to the heterogeneous structure an xml document can have, the xml input reader does not always create exactly the same model structure (in contrast to the java input reader). For example the model’s depth differs strongly, according to it’s input document. To allow navigational access to the nodes, the model also depends on the document’s element’s node names. All child elements with unique names, are directly accessable via their names. In addition it is possible to iterate over all child elements with held of the child list Children. So it is also possible to access child elements with non unique names.

The XML input reader will create the following object model for template creation (EXAMPLEROOT, EXAMPLENODE1, EXAMPLENODE2, EXAMPLEATTR1,…​ are just used here as examples. Of course they will be replaced later by the actual node or attribute names):

• ~EXAMPLEROOT~ ('Map<String, Object>' :: common element structure)

  • _nodeName_ ('String' :: Simple name of the root node)

  • _text_ ('String' :: Concatenated text content (PCDATA) of the root node)

  • TextNodes ('List<String>' :: List of all the root’s text node contents)

  • _at_~EXAMPLEATTR1~ ('String' :: String representation of the attribute’s value)

  • _at_~EXAMPLEATTR2~ ('String' :: String representation of the attribute’s value)

  • _at_…​

  • Attributes ('List<Map<String, Object>>' :: List of the root’s attributes

    • at ('Map<String, Object>' :: List element)

      • _attName_ ('String' :: Name of the attribute)

      • _attValue_ ('String' :: String representation of the attribute’s value)

  • Children ('List<Map<String, Object>>' :: List of the root’s child elements

    • child ('Map<String, Object>' :: List element)

      • …​common element sub structure…​

  • ~EXAMPLENODE1~ ('Map<String, Object>' :: One of the root’s child nodes)

    • …​common element structure…​

  • ~EXAMPLENODE2~ ('Map<String, Object>' :: One of the root’s child nodes)

    • …​common element sub structure…​

    • ~EXAMPLENODE21~ ('Map<String, Object>' :: One of the nodes’s child nodes)

      • …​common element structure…​

    • ~EXAMPLENODE…​~

  • ~EXAMPLENODE…​~

In contrast to the java input reader, this xml input reader does currently not provide any additional template methods.

Merger extensions

The XML plugin uses the LeXeMe merger library to produce semantically correct merge prodcuts. The following four merge strategies are implemented and can be configured in the templates.xml:

• xmlmerge: In case of a conflict the base value is preferred

• xmlmerge_override: In case of a conflict the patch value is preferred

• xmlmerge_attachTexts: In case of a conflict the base value is preferred. Attributes and text nodes will be merged where possible

• xmlmerge_override_attachTexts: In case of a conflict the patch value is preferred. Attributes and text nodes will be merged where possible

Currently only the document types included in LeXeMe are supported. On how the merger works consult the LeXeMe Wiki.