What is the purpose and/or gain (other than increased readability for creating/deleting attributes) to nesting an XmlConfig
element in another XmlConfig
element?
Example of what I'm referring to (I'm using WiX 3.6):
<util:XmlConfig ...>
<util:XmlConfig ... />
</util:XmlConfig>
The short answer: the only purpose of the option to have nested <util:XmlConfig>
elements is to be able to add/remove attributes to/from the newly created elements in a more readable way. So, this is basically what you assumed.
Consider the following initial XML file:
<?xml version="1.0" encoding="utf-8"?>
<cars>
<car name="ford" type="minivan"/>
<car name="toyota" type="sedan"/>
<motos>
<moto name="honda" model="shadow" type="cruiser" />
</motos>
</cars>
In order to add another <moto>
to it, the following WiX snippet can be used:
<util:XmlConfig Id="elem1" Action="create" ElementPath="cars/motos" File="$(var.XmlFilePath)" Node="element" On="install" Name="moto">
<util:XmlConfig Id="elem11" ElementId="elem1" Name="name" Value="yamaha" File="$(var.XmlFilePath)" />
<util:XmlConfig Id="elem12" ElementId="elem1" Name="type" Value="chopper" File="$(var.XmlFilePath)" />
</util:XmlConfig>
As a result, the XML file ends up as follows:
<?xml version="1.0" encoding="utf-8"?>
<cars>
<car name="ford" type="minivan"/>
<car name="toyota" type="sedan"/>
<motos>
<moto name="honda" model="shadow" type="cruiser" />
<moto name="yamaha" type="chopper" />
</motos>
</cars>
Couple of things to note here:
- the
Action
attribute can't be defined in inner XmlConfig
elements, and that's logical - it is the same as the one of the parent element
- the
Node
attribute can't be defined as well, because only attributes are allowed
- the weird thing is that you have to specify
File
attribute each time - seems to be a design issue here
- the
ElementId
attribute should point to the parent element you are adding the attributes to, and that's also strange as it could also be "guessed" from the nested code
Anyway, if you do want to create an XML subtree structure, the elements which end up as nested elements in resulting XML are made by XmlConfig
elements placed on a same level. So, the following snippet:
<util:XmlConfig Id="elem1" Action="create" ElementPath="cars/motos" File="$(var.XmlFilePath)" Node="element" On="install" Name="moto" Sequence="1">
<util:XmlConfig Id="elem11" ElementId="elem1" Name="name" Value="yamaha" File="$(var.XmlFilePath)" />
<util:XmlConfig Id="elem12" ElementId="elem1" Name="type" Value="chopper" File="$(var.XmlFilePath)" />
</util:XmlConfig>
<util:XmlConfig Id="elem2" Action="create" ElementPath="cars/motos/moto[\[]@name='yamaha'[\]]" File="$(var.XmlFilePath)" Node="element" On="install" Name="extra" Sequence="2">
<util:XmlConfig Id="elem21" ElementId="elem2" File="$(var.XmlFilePath)" Name="bags" Value="leather" />
</util:XmlConfig>
will transform the XML as follows:
<?xml version="1.0" encoding="utf-8"?>
<cars>
<car name="ford" type="minivan"/>
<car name="toyota" type="sedan"/>
<motos>
<moto name="honda" model="shadow" type="cruiser"/>
<moto name="yamaha" type="chopper">
<extra bags="leather"/>
</moto>
</motos>
</cars>
Pay attention to the following:
- the
XmlConfig
elements are placed on the same level, although they result in a nested elements in the resulting XML
- the
Sequence
attribute is important, in case you add an attribute or a child to the element, which is also being created
Hope this makes more sense now. Sorry for the wrong answer given initially.