ParameterConditionRule

Control parameter values via a set of conditions.

This rule is similar to product rules in the sense that it allows to pilot product parameter values, based on some conditions. However, it goes a little further than a product rule as it has access to more context and thus can solve very specific business needs than cannot be addressed by product rules.

Notification level: Not applicable

Key	Value
ID	`ParameterConditionRule`
Translation key	Not applicable

Behavior

This rule gives the ability to pilot several parameters. It behaves the same for each parameter independently, so the current section explains the behavior for one parameter only. For the example, the controlled parameter is named foo.

When executed on a cabinet (See the trigger conditions below), the ParameterConditionRule follows these steps:

Retrieve the applicable sub-products. These are all level-2 products that possess the parameter foo.
On each of these applicable sub-products, apply the rule conditions one by one and stop at the first condition that is met.
Apply the value corresponding to this condition to the parameter foo. If no condition is met at the previous step, the current value remains.

Notes

a level-2 sub-product is a sub-product directly under the top product.

the values are always applied on the level-2 sub-products retrieved during the step 1. The top-product is not modified directly.

In this example, it is important that the parameter foo is not present on the top-product. It must only be defined on the level-2 sub-products that you need the rule to work on.

Trigger Conditions

The ParameterConditionRule is triggered when these events occur:

Opening a project : the rule is executed on all the project products
Adding a cabinet : the rule is executed on this cabinet
Changing a product parameter : the rule is executed on this product
Customizing a cabinet : the rule is executed on the customized cabinet after validating changes in the cabinet editor

Supported conditions

The ParameterConditionRule supports several "conditions" that can be used to control parameter values. Supported conditions are:

Condition	Description
`top-id`	The condition is met if the top-product has an ID contained in the `idList` key.
`z-collision`	The condition is met if the level-2 sub-product is in front of any other sub-product whose ID is in the `idList` key. The check is only performed in the Z direction. For example, if `idList` contains the ID of a freezer, and if the applicable level-2 sub-products are the product doors, the condition will be met for every doors that are in front of a freezer (i.e. intersect in the Z direction).
`parameter`	The condition is met if the level-2 sub-product has the parameter defined by `parameterName` and if this parameter currently holds one of the values defined in `parameterValues`.
`none`	This condition is always met. For that reason, any condition setup after it will never be evaluated. So if defined, the `none` condition should be the last of the steps.

Overload Parameter

The overload is formatted as a JSON object, in which each property is a parameter name.

The value associated to each parameter name is a JSON object with the following structure.

Key name	Type	Default value	Description
`type`	number	–	Mandatory The parameter type. For example 7 is for a Product type parameter.
`steps`	array of objects	–	Mandatory The list of conditions to apply one by one to control the parameter.

The steps key contains an array of JSON objects, each representing a condition. The following table presents the general structure of a condition object.

Key	Type	Default value	Description
`condition`	string	–	Mandatory The kind of condition. Accepted values are: ▪️ top-id ▪️ z-collision ▪️ parameter ▪️ none
`targetValues`	array	[]	Optional A list of values to apply to the controlled parameter if the current condition is met. The rule applies the first available value (in terms of dates) from this list. The type of data exposed in this array depends on the controlled parameter type. Note that for product typed parameters, the expected values in this array are the product IDs as strings.
`defaultValue`	boolean	false	Optional If set to true, the rule applies its default value to the controlled parameter if the current condition is met. If `targetValues` is provided, `defaultValue` is ignored and `targetValues` is used instead to determine the value to apply.
`idList`	array of string	–	Mandatory for `top-id` and `z-collision` conditions. Ignored for other conditions If the condition is `top-id`, the `idList` key must contain the list of top product IDs to check. If the condition is `z-collision`, the `idList` key must contain the list of sub-product IDs for which we have to check for a z-collision.
`parameterName`	string	–	Mandatory for `parameter` conditions. Ignored for other conditions Defines the parameter name to check on the level-2 sub-product.
`parameterValues`	array	–	Mandatory for `parameter` conditions. Ignored for other conditions Defines the list of parameter values to check on the level-2 sub-product, for the parameter `parameterName`. The type of data exposed in this array depends on the parameter type of `parameterName`. Note that for product typed parameters, the expected values in this array are the product IDs as strings.

Examples of each supported condition objects

the top-id condition

Here is an example of a top-id condition:

{
        "condition": "top-id",
        "idList": [
                "Corner_45_base",
                "Corner_45_wall"
        ],
        "targetValues": [
                "Hinge_90_deg"
        ]
}

When evaluating this example condition, it checks if the top-product has a product ID of "Corner_45_base" or "Corner_45_wall". If this is the case, the condition is triggered and the value "Hinge_90_deg" is applied to the controlled parameter.

the z-collision condition

Here is an example of a z-collision condition:

{
        "condition": "z-collision",
        "idList": [
                "Inner_Drawer_400",
                "Inner_Drawer_600",
        ],
        "targetValues": [
                "Hinge_150_deg"
        ]
}

When evaluating this example condition, it checks if the applicable level-2 sub-product intersects (in the Z direction) one other sub-product with an ID of "Inner_Drawer_400" or "Inner_Drawer_600". If this is the case, the condition is triggered and the value "Hinge_150_deg" is applied to the controlled parameter.

the parameter condition

Here is an example of a parameter condition:

{
        "condition": "parameter",
        "parameterName": "front",
        "parameterValues": [
                "Special_Front_ID"
        ],
        "targetValues": [
                "Hinge_100_deg"
        ]
}

When evaluating this example condition, it checks if the applicable level-2 sub-product has a parameter named "front" and if the current value of this parameter is "Special_Front_ID". If this is the case, the condition is triggered and the value "Hinge_100_deg" is applied to the controlled parameter.

the none condition

Here is an example of a top-id condition:

{
        "condition": "none",
        "defaultValue": true
}

When evaluating this example condition, the condition is always met. In this case also, there is no targetValues but a defaultValue key instead with the value true. So the controlled parameter is set back to its default value.

Note that defaultValue is not specific to the condition none and can be used with any condition. Similarly, targetValues can be used with the condition none without problem.

Overload complete example

Here is a concrete example of this rule with the case of a parameter named "hinge". Note that there can be several controlled parameters in this rule (the below example illustrates that with the parameter foo at the end).

{
    "hinge": {
        "type": 7,
        "steps": [
            {
                "condition": "top-id",
                "idList": [
                        "Corner_45_base",
                        "Corner_45_wall"
                ],
                "targetValues": [
                        "Hinge_90_deg"
                ]
            },
            {
                "condition": "top-id",
                "idList": [
                        "Corner_90_base"
                ],
                "targetValues": [
                        "Hinge_95_deg"
                ]
            },
            {
                "condition": "z-collision",
                "idList": [
                        "Inner_Drawer_400",
                        "Inner_Drawer_600",
                ],
                "targetValues": [
                        "Hinge_150_deg"
                ]
            },
            {
                "condition": "z-collision",
                "idList": [
                    "Integrated_Freezer"
                ],
                "targetValues": [
                    "Hinge_155_deg"
                ]
            },
            {
                "condition": "parameter",
                "parameterName": "front",
                "parameterValues": [
                    "Special_Front_ID"
                ],
                "targetValues": [
                    "Hinge_100_deg"
                ]
            },
            {
                "condition": "none",
                "defaultValue": true
            }
        ]
    },
    "foo": {
        "..."
    }
}

Semantically, this example can be summarized as follow.

For each level-2 sub-product that has the parameter "hinge", typically the doors of the cabinet in this example:

if the top cabinet is "Corner_45_base" or "Corner_45_wall", put a 90° hinge
else if the top cabinet is "Corner_90_base", put a 95° hinge
else if the door is in front of a "Inner_Drawer_400" or a "Inner_Drawer_600", put a 150° hinge
else if the door is in front of a "Integrated_Freezer", put a 155° hinge
else if the door has a parameter front with the value "Special_Front_ID", put a 100° hinge
else rollback to the default value

Notes

The condition "z-collision" can affect slightly the planner performances if defined too many times. Use it with caution, and always prefer to put it as far as possible in the steps array (because conditions are evaluated in order and the algorithm stops at the first met condition).

Though it is possible to control multiple parameters with this rule, it is advised to control as few as possible and to prefer product rules when possible, for performance reasons. The purpose of this rule is to handle particluar cases and not to replace a correct configuration of the range and product rules.

Lastly, be very cautious with the parameter condition because it is possible to create an infinite loop if badly configured. The planner does not verifies such loops, so the result will be an out-of-memory crash. Here is an example of the smallest condition list that creates an infinite loop:

{
    "foo": {
        "type": 1,
        "steps": [
            {
                "condition": "parameter",
                "parameterName": "foo",
                "parameterValues": [ 1 ],
                "targetValues": [ 2 ]
            },
            {
                "condition": "parameter",
                "parameterName": "foo",
                "parameterValues": [ 2 ],
                "targetValues": [ 1 ]
            }
        ]
    }
}

pre-released

Using Product Catalog

Customizing cabinets

Parameters for Products

Parameters for Linears

Default Widgets

Cabinet Interaction Rules

Ceiling Rules

Appliance Rules

Worktop Corner Cut Operation Rules

Worktop Cut-Out Operation Rules

Worktop Edge Cut Operation Rules

Worktop Joint Operation Rules

Worktop Compatibility Operation Rules

Worktop Combination Operation Rules

Wall Panel Corner Cut Operation Rules

Wall Panel Cut-Out Operation Rules

Wall Panel Edge Cut Operation Rules

Wall Panel Compatibility Operation Rules

Wall Panel with appliance Rules

Apply Rules

BOM Rules

Pilot Product Parameters with Specific Conditions