You should put a bindRef on the Form Panel where the Fragment is associated. And for multiple use of same Fragment, this bindRef could be different.
For example, for Business Address Panel having Address fragment, if you put bindRef as /root/businessAdress & for Home Address if you use bindRef /root/homeAdress, the generated XML should be
For differences b/w, 6.1 & 6.2, can you post the generated XML that was produced for 6.1 v/s 6.2?
Hi Robert,In addition to what Deepak, mentioned, you can also add indices in the bindRef property of the container panel of the fragment. for example /root/Address, /root/Address ...The idea is to assign unique xpaths, in the bindRef property so that the different fields map to different subtrees of the data xml on submission.Form 6.2 onwards, all fields which map to same xpaths in the submit xml are "synced" so that value entered in one field is reflected in the other in accordance with what data is submitted.
Let me elaborate further with a concrete example.
Suppose you have a "Person" schema with the following structure (refer attached file) :
personType -> (firstName : stringType, homeAddress : addressType, officeAddress : addressType)
addressType -> (houseNumber : intType, street : stringType)
Now we can make a form fragment called "Address" corresponding to the "addressType" complextype, and a form "Person" corresponding to the "personType" schema root, using the same schema.
In the "Person" form you can drag and drop the "Address" fragment twice, to correspond to the "officeAddress" and "homeAddress" child elements of the Person element.
But just dragging and dropping a fragment, is not enough to associate a fragment to a particular type in the schema. you need to set up the association to a particular element in the parent schema.
This is achieved by editing the "Bind Reference" property of the panel containing the fragment. You directly set it up as "/person/officeAddress" for the "Office Address" section or use the "Browse data model" button beside the property field to select an element from the schema model tree. you need to do the same for the "House address" panel.
Doing this ensures that the data filled in by the user is mapped to the correct sub trees of the final submit xml to be generated on form submission; which can be further validated against the xsd schema used to create the form.
If one does not map a fragment to the corresponding element in the parent schema, there is no way to judge which subtree in the xml the entered data is to stored. This will cause data loss as all repeated, fragments, without the "Bind Ref" set up properly will end up in the wrong subtree in the final xml (by default parallel to the schema root element). Further, since all such fragments, are mapped to the same subtree, only the last fragment's data will be retained.
So one must set up the bind references properly to ensure data doesnt get clobbered in the submission xml.
On the flip side, setting up same bind reference, on different items, is an easy way to capture/show the same information in different places in the form. This feature to sync data from one field to another having same bind references was added in 6.2.
This is the reason why you have been seeing duplication of data in your forms. earlier there was no indication of data clobbering on submission, during form fillup, one had to inspect the submitted dataxml. If you check out your earlier forms' data you will find that these fragment's data were clobbered.
P.S. : As a side note "bind reference" is nothing but the xpath to the subtree where the item's data will be stored in the submit xml, for forms with xsd schema based form models.
For forms without data models, the "name" property of the item is used as the bind reference, relative to the xml root.
person.xsd.txt.zip 457 bytes