You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A bit of context: Mete presented the inclusion subgraph/update bubbling frontend feature last week when a lot of comments came from different people.
Also during that meeting we observed that the final update seemed not to work, looked like the backend does not perform the update.
Since then I checked the functionality, and the backend actually performs the update. This can be seen if one checks the embedder artifact (template or element) by the means of the REST API, or just checks the Network panel in the Inspector of the browser.
On the frontend, changes other than schema:name and schema:description are reflected.
Unfortunately, the old frontend seems to use the "key" of the child (the name of the node in the container element's properties node - which is not changed after a successful update) and somehow overwrites the schema:name with it when starting up the editor. The schema:description also seems to be overwritten with an empty string.
This means that if you just check the JSON shown on the UI, that is already altered, and looks like it was not updated. And if you save it in this state, of course, it will be overwritten.
This is obviously a frontend bug/shortcoming, rooting in the fact that at the beginning (several years back) we and also whoever worked on the frontend , we supposed that the schema:name and the key of the child will be equal. There are indications of this in the behavior of the editor: the fact that these are not editable separately.
The editor tries to do its best on keeping the key unique (if the same element or field is included twice) but this also leads to strange situations.
During our work on the model libraries with Martin, we've seen this issue, and we agreed this this must be fixed. At that point did not seem like a priority (it is a bad situation, but it is like this for several years, and nobody complained). But now this feature brought the issue up again.
So what I would propose is to test this feature in this form, or even go live with it if we need to show that it is done.
But in the meantime I would prefer to start working on this fix, which does not seem trivial.
The text was updated successfully, but these errors were encountered:
For example, if we have a template with a field called "Field1", the field key name in the JSON Schema should match the schema:name of the field itself:
A bit of context: Mete presented the inclusion subgraph/update bubbling frontend feature last week when a lot of comments came from different people.
Also during that meeting we observed that the final update seemed not to work, looked like the backend does not perform the update.
Since then I checked the functionality, and the backend actually performs the update. This can be seen if one checks the embedder artifact (template or element) by the means of the REST API, or just checks the Network panel in the Inspector of the browser.
On the frontend, changes other than schema:name and schema:description are reflected.
Unfortunately, the old frontend seems to use the "key" of the child (the name of the node in the container element's properties node - which is not changed after a successful update) and somehow overwrites the schema:name with it when starting up the editor. The schema:description also seems to be overwritten with an empty string.
This means that if you just check the JSON shown on the UI, that is already altered, and looks like it was not updated. And if you save it in this state, of course, it will be overwritten.
This is obviously a frontend bug/shortcoming, rooting in the fact that at the beginning (several years back) we and also whoever worked on the frontend , we supposed that the schema:name and the key of the child will be equal. There are indications of this in the behavior of the editor: the fact that these are not editable separately.
The editor tries to do its best on keeping the key unique (if the same element or field is included twice) but this also leads to strange situations.
During our work on the model libraries with Martin, we've seen this issue, and we agreed this this must be fixed. At that point did not seem like a priority (it is a bad situation, but it is like this for several years, and nobody complained). But now this feature brought the issue up again.
So what I would propose is to test this feature in this form, or even go live with it if we need to show that it is done.
But in the meantime I would prefer to start working on this fix, which does not seem trivial.
The text was updated successfully, but these errors were encountered: