Passing binding from the parent form to fragments

[#1]

So one of the concepts that makes object oriented design and programming powerful is reusing components/objects. The idea is create it once, make it solid, then reuse it over and over again.

Where I'm at is that we have a form fragment that defines an address. The binding and name are defined in the fragment for the individual fields. The problem is that I have a form that uses this fragment over and over for different address types. The problem is that the binding and the name of the field is always the same and when one address is filled in, the value is propagated to all of the other fragments. This used to work better in 6.1 but in 6.2, all of the fragments become the same control. One way to get around this is to create a fragment for each address type but that loses all of the advantages of OOD.

Is there a way to override the binding from the parent form level so that the child fragments' binding can be changed as the form is built? This would be a great feature so that OOD can be used to make building of complex forms much easier. A programmer/designer could build a bunch of fragments that authors could use to build forms without having to define every single piece of the form.

[#2 · Accepted solution]

Hi Robert,

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 ‏1 KB

[#3]

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[1], /root/Address[2] ...

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.

[#4]

Hi,

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 

<root><businessAddress><Street>businessTt1</Street></businessAddress><homeAddress><Street>homeSt1</Street></homeAddress></root>

For differences b/w, 6.1 & 6.2, can you post the generated XML that was produced for 6.1 v/s 6.2?