As Sharath says, you will need to define your own XType, instead of putting multiple fields in the multfield itself.
As an alternative to concatenating fields in the String[] property, another approach is to create child nodes for each added field, for example. but not:
<links link="[Example|http://example.com,Google|http://google.com]"/>
As a result, you will receive:
<links> <link_1 title="Example" url="http://example.com"/> <link_2 title="Google" url="http://google.com"/> <links>
You can read the values back without having to parse them from the String value. It also means that things like rollout, which update path fields, should work like standard ones.
The code is too long to be fully produced here, but there is a good starting point for this on the Adobe forums here . (It has an Adobe copyright notice, but is submitted by the user - not sure of its official status, but good as a reference implementation; EDIT: possibly linked to the Citytechnic MultiCompositeField on Github , as ery points out ).
The above example also uses the same approach as the multifield itself, i.e. it reads from the fieldConfig node of the composite and creates a property for each record on the child nodes that it creates.
This makes the composite field completely reusable, since you only need one composite XType no matter how many options you want to create, i.e. will allow you to choose the approach that you outline in the question:
<links jcr:primaryType="cq:Widget" fieldLabel="QuickLinks" name="./links" xtype="mtmulticompositefield"> <fieldConfigs jcr:primaryType="cq:WidgetCollection"> <title jcr:primaryType="cq:Widget" fieldLabel="Title" hideLabel="{Boolean}false" name="./jcr:title" xtype="textfield"/> <url jcr:primaryType="cq:Widget" fieldLabel="URL" name="./jcr:url" xtype="textfield"/> </fieldConfigs> </links>
It also allows the use of more complex XTypes as children, for example. images without further work.