Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template editor does not differentiate between schema:name and key in the parent #994

Open
egyedia opened this issue Jun 5, 2024 · 1 comment
Assignees
Labels

Comments

@egyedia
Copy link
Member

egyedia commented Jun 5, 2024

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.

@martinjoconnor
Copy link
Member

martinjoconnor commented Jun 5, 2024

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:

{
  "@type": "https://schema.metadatacenter.org/core/Template",
  ...
  "properties": {
    "@context": { ... },
    "Field1": {
      "@type": "https://schema.metadatacenter.org/core/TemplateField",
      "@context": { ...  },
      "schema:name": "Field1",
      "schema:description": "Help Text"
    }
}

We have discovered that this is not always the case.

The same issue occurs for element names. Also an issue for field and elements nested inside elements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants