Associating a schema def'n with a field that is in a fragment

[Amal_Elaine]

[xpost from livecycle google group]:

So we are designing lots of forms and orchestrations, so obviously we have many re-usable components that are turned into fragments.  I'm discovering that you cannot associate a schema field definition with a field that is contained within a fragment on the form.

So I'm finding that we are changing our process to first look at the orchestration, and then, if a field needs to be referenced in an orchestration, then we have to make sure that the field is NOT contained in a fragment so that we can hook up a schema definition to that field (so that it's easy to refer to the field via a process variable)...

Imagine having a block of fields that make up a beautiful fragment, only having to leave out a field because it's needed in an orchestration.  Yuk, bleh, nyet, hooey...

If I'm mistaken, please correct me.  ;-)

Thanks,
Elaine

[Former Community Member · Accepted solution]

I am not sure that I follow. When designing a fragment you should be using relative binding so that your fragment can be used with any schema that follows that convention. Then when you use your fragment in your main form, you simply have to bind your fragment root subform to the appropriate node in the schema, then everything else below that node will bind based on that one binding expression. For example if I have an address bock structure as follows:

<Address>

   <HouseNumber/>

   <Street/>

   <City/>

   <State/>

   <Zip/>

</Address>

Now when I design my fragment if I bind the root subform to <Address> ....then bind all other nodes to their respective nodes the binding will look like $.Street. This is relative binding ...each item looks to the parent container for its binding (in this case Address) then adds on the part that it carries (.Street).

Now when you use the fragment in your form you simply have to modify the binding on the root container to <Address> in the schema and all parts below it will work "automagically". Also any schema that uses this structure will be able to use this fragment....its simply a case of binding the root of the fragment to the appropriate node in the schema.

Hope that helps

Paul

[Amal_Elaine]

Thanks Paul,

Does this mean that the fragment does not need to have a schema assigned to itself?  Is it fair to say that the parent form will contain the schema definition and the fragment will be linked into this definition?  Can you provide a simple example?

What about the case where there are fragments within fragments?  Same principle?

[Former Community Member]

The fragment does not have a unique schema associated with it but it can have a common schema. In this case use relative bindings to that schema, then when the fragment is used in the form the fragment subform gets bound to the parent node that contains the nodes represented in the fragment. This allows you to reuse the fragment scross multiple schemas (that have the same structure as the fragment). Otherwise you are creating a unique fragment for each schema definition that you want. Fragments in Fragments can follow the same principle but you can see how it woudl become very complicated in a short time (using bindings anyways).

There are samples that ship with the product .....look in the Designer install folder under this directory:

EN\Samples\Forms\Purchase Order\Form Fragments

Paul

[Amal_Elaine]

Thanks Paul,  we have looked at the samples.  Either the forms contain a schema but no fragments, or the forms contain fragments but no schema.  We'd really like to see a completed sample form that makes use of fragments and a schema, and shows how the fragment is linked to the schema. 

We're getting there, ... 

Thanks!