feat(ontologies-endpoint): add new cardinalities check route (DEV-1704) #499
Conversation
DEV-1704 Teach JS-Lib new routes
In the course of the "Changing of Cardinalities" project a new route to dsp-api was added, which allows for a pre-update check of whether a specific cardinality can be set on a class/property combination: The request if it fails now also contains the reasons for the failure as it is using the same pre-update check as above. Both features are available in the latest release. However, the documentation did not make it, but you can find the documentation in the following PR: https://github.com/dasch-swiss/dsp-api/pull/2420/files Especially take a look at chapter "Replacing the Cardinalities of a Class" and its paragraph "Pre-Update Checks" where the new endpoint and new response are described. |
| export const getCardinalityString = (cardinality: Cardinality): string => { | ||
| switch(cardinality) { | ||
| case Cardinality._0_1: | ||
| return "0-1" | ||
| case Cardinality._0_n: | ||
| return "0-n" | ||
| case Cardinality._1: | ||
| return "1" | ||
| case Cardinality._1_n: | ||
| return "1-n" | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Wouldn't be nicer to make a Map<Cardinality, string> a const and then .get the value or for...of the keys, just instead of 2 switches.
There was a problem hiding this comment.
Doing this would make it more flexible but I'm not sure if it's really needed. I have the second switch in the app component because I don't have access to Cardinality in the template to pass it into the method. I'm not sure if this would ever actually be an issue in the DSP-APP. Having said that, I can try it out and see how it works.
| const canDelete = page.getEle('div button.can-replace-card-for-res-card'); | ||
| canDelete.click(); |
There was a problem hiding this comment.
Just to confirm this is not needed anymore?
There was a problem hiding this comment.
this was incorrectly named probably due to copy-pasting
resolves DEV-1704