In most cases where nested (child) configurators are used, information will be passed to the child from the parent configurator during run time. These are usually system level choices made by the user that would be common to all the children. Selecting this value one time in the parent and passing it to the children eliminates your user from having to make the same selection over and over in all the children.
A value rule is the recommended place to perform this work, because the information usually needs to be updated whenever the user makes a change to the UI.
Create a nested configurator based on user action
A rule for a button field on the parent, so clicking the button adds a configurator to the specified page in the parent configurator. Each click will add a new child.
Create a nested configurator, overriding default values
When adding a nested configurator, you can also override the default field values defined in that child configurator. Click the "+" mutation button on the "Add nested configurator" block, and overrride as many field values as you need.
Set A Field Value In All Children
Given a parent configurator having a field called "Layers", use a value rule to ensure that the requested number of layers exist as child configurators. Note how each child is given a name such as "Food Layer 1", "Food Layer 2", and so on. Also, note that we specify a container on the parent, called "Child Layers" in this example, where we want the nested configurators to appear.
Think of the "Add nested... if not exists" block seen here like an insurance policy.
- It will ensure the configurator you need exists, creating it if necessary.
- If you use the mutation technique above to set default field values, this block will also ensure that the fields are set correctly, too, even if the nested configurator already exists.
Set A Field Value In A Single Child
In the below example, a loop is used along with the 'From Nested' block to access all nested configurators and set a field named 'fShowLogo' to a value of 'true'.
Two major weaknesses exist in the above example.
- It assumes that all the nested configurators are 'Conveyor' configurators. If one of them was not of type 'Conveyor', a run time error might occur.
- It assumes is made that a field with the name of 'length' exists. If the field does not exist (say, because the nested configurator is not a 'Conveyor' configurator and doesn't have this field), a run time error will occur.
Both weaknesses are easy to solve. Just ensure that the configurators you are looping through are of the correct design. You can ensure this through two techniques:
-
Check the child's design before you write to it.
Each configurator has an 'idProduct' property: it's the same unique ID you see in the list of configurators. Check this property of the child in a conditional statement to be sure that child is of the right type. Here's an example:
In this example the nested 'Conveyor' configurator is known to be ID = 85, so by filtering the collection of possible nested configurators to this ID ensures our update to the conveyor configurator field 'length' is run only against a configurator which actually has that field.
-
Loop through just the children you need, instead of all children.
When child configurators are added to a parent, you can add them under a specific page. That page can be visible or hidden. In this way, you can use the parent's pages almost like folders to keep the children organized. In our example, if we ensure that the 'Conveyor' child configurators are only added to a page in the parent called 'Chassis List', then we can confidently loop through the children stored under that correct page to get or set what we want.
The 'From Nested' block may be used without a loop in which case a reference to the specific instance of the child is required in lieu of the loop variable. In the following example, the name of the child, "Chassis 1" is used
The child reference may also be from the nested configurator collection of the parent. In this example, the 4th child (index = 3) in the collection is used as the reference.
The weaknesses described above above are also present in this example. The 4th item in the nested configurator collection may or may not be of type 'Chassis'. Caution must be observed when using this method.