Closed georgevbsantiago closed 7 months ago
We are releasing two modifications here:
The PATCH Property API will now update only the fields present on the form. It was already functioning with flattened JSON values, i.e., the following example only updates "fieldA" and "fieldB":
{
"value.fieldA": 200,
"value.fieldB": 300
}
From now on, it will support a more generic way, allowing you to provide just the JSON values for updating, matching the format available on the property form:
{
"value" : {
"fieldA": 200,
"fieldB": 300
}
}
Another update is the ability to select any parent node (with nested values), or all property values by not selecting any field. For example, in the following illustration, 'nested' is presented as a selectable value. This enhancement makes it easier for an HTML widget to receive multiple values.
:clap::clap::clap::clap::clap::clap::clap::clap::star2::star2::star2::star2:
This issue originates from this post (link)
I investigated further and identified that there is a possible limitation in the API.
I was able to preserve the value that was not contained in the form (“d” variable) by adding the “d” variable in the HTML Widget configuration. (see image below)
However, this approach has limitations: 1 - All JSON fields (device property JSON) must be declared in the settings. This is a difficulty in JSONs with many large fields (with 15, 20, 25… fields). This requirement is not flexible, as if the JSON changes, we have to change all the HTML Widgets and add the new fields. Also, if the user wants to update just one or two fields of the JSON, he will be required to include all fields (15, 20, 25…) in the HTML Widgets configuration; 2 - If the JSON is nested (
{“level_1”: {level_2: “n2”}
}, the variable in $scope.value appears as level_1.level_2 and when saving the JSON it is no longer multilevel, to be singlelevel. It is possible to work around defining the JSON schema ({"level_1": {level_2: $scope.value.level_1.level_2}}
), but it is not flexible as the JSON schema can change@jaimebs, would it be feasible and possible to change the API (or build a new API) behavior to work with the above proposal? The API would be much more flexible.