Define Custom Contexts for Components in a Layout
In addition to built-in system variables that can be used within a dynamic component (for example, device size or user role), you can define a context to pass information that might otherwise be inaccessible to a dynamic component. This information can be values produced by your application that come from outside your layout, such as page variables, or details from other parts of your application.
For example, your application might have some preferences that could be useful when you're using a dynamic table or form to build a layout. These preferences can be any arbitrary value, but as a layout developer, you don't want your layout to consume values that might not be valid. So Visual Builder provides a componentContextType, a contract that helps you define the shape—or parameters—that the component context will accept. Once the componentContextType is defined, these parameters become part of the $componentContext system variable and can be used anywhere in the layout. Here's an example of $componentContext parameters in the rule set condition builder:
Visual Builder also provides the baseComponentContextType to define parameters at the service level. Much like componentContextType, parameters defined by the baseComponentContextType contract can be used anywhere in the layout where the $componentContext variable is available. But unlike component context parameters, base component context parameters can also be used in OpenAPI schema.
isOAuth2enabled
field, then bind that to the query parameter of the URL in the openapi.json
file:"employees": {
"operationRef": "http://example.com/hrApi/resources/1.0/employees/describe#/paths/~1employees/get",
"parameters": {
"token": "AUTH_TOKEN=[[$componentContext.securityInfoMap.isOAuth2Enabled ? 'foo' : 'bar' ]]"
}
}
The baseComponentContextType is the contract that makes it valid to use $componentContext.securityInfoMap.isOAuth2Enabled
in openapi.json
.
To define parameters that can be passed to a layout: