CVOC : Adding hidden metadata fields (Ontoportal integration) #10503
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| ## Release Highlights | ||
|
|
||
| ### Updates on Support for External Vocabulary Services | ||
|
|
||
| #### Hidden HTML Fields | ||
|
|
||
| To enlarge javascript possibilities of [:CVocConf](https://guides.dataverse.org/en/6.3/installation/config.html#cvocconf) configured service, the child fields of the configured field had been added to the dataset metadata view. | ||
| Those values are hidden and can be found with the html attribute `data-cvoc-metadata-name`. (#10503) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -159,6 +159,17 @@ | |
| <f:passThroughAttribute name="data-cvoc-protocol" value="#{cvocConf.get(dsf.datasetFieldType.id).getString('protocol','')}" /> | ||
| <f:passThroughAttribute name="data-cvoc-managedfields" value="#{cvocConf.get(dsf.datasetFieldType.id).get('managedfields').toString()}" /> | ||
| </h:outputText> | ||
| <!-- Cvoc for others fields --> | ||
| <h:outputText value="#{cvPart.key.value}" | ||
| escape="#{cvPart.key.datasetFieldType.isEscapeOutputText()}" | ||
| rendered="#{(cvocOnDsf or cvocOnCvPart) and not ( | ||
| cvPart.key.datasetFieldType.name.equals(cvocConf.get(cvPart.key.datasetFieldType.id).getString('term-uri-field')) | ||
| or cvPart.key.datasetFieldType.name.equals(cvocConf.get(dsf.datasetFieldType.id).getString('term-uri-field')))}" | ||
| styleClass="hidden"> | ||
| <f:passThroughAttribute name="hidden" value="hidden" /> | ||
| <f:passThroughAttribute name="data-cvoc-metadata-name" | ||
| value="#{cvPart.key.datasetFieldType.name}" /> | ||
| </h:outputText> | ||
|
Member
There was a problem hiding this comment. I think this works. A possible alternate design would be to use a data-cvoc-managed-fields element in the term uri span that has a json object with managed field names: values. That might be more SPA friendly. Not sure how how much effort it might take on the Java side to construct the value or whether changing is worth the effort at this point. @luddaniel - any thoughts?
Contributor
There was a problem hiding this comment. In order to avoid introducing any blocking changes, we have opted to add hidden metadata. So existing Javascript files like skosmos.js or ror.js don't have to be modified to keep working. I imagine that for SPA, metadata will be retrieved via API, probably using an endpoint providing the JSON representation of a datasetversion (based on its ID ?). But maybe I'm wrong ?
Member
There was a problem hiding this comment. I don't think there's any backward compatibility issue in either design - the old scripts are either ignoring extra hidden DOM elements or extra attributes in the DOM element they normally look at. My point about SPA-friendly may be incorrect - I was assuming, like I think you are, that the SPA would be getting the list of fields/values via some API, as JSON, and then guessing that dumping the JSON for the necessary fields into an attribute would be less work than generating more DOM elements. That may or may not be the case. I wouldn't be surprised if the SPA needs breaking changes in the cvoc mechanism anyway, so this could be something we discuss when the SPA cvoc design starts. Overall, I'm raising this for two reasons - one is just to write down the possible alternative somewhere, and two is to see if you thought this was worth making a change now. If not (doesn't sound like it) I don't think it's a big enough issue to hold up the PR/ go discuss in a larger group, etc., so I can go ahead and approve the PR as is.
Contributor
Author
There was a problem hiding this comment. Hello @qqmyers , we discussed with @jeromeroucou to understand the depth of your point, here are our views :
Member
There was a problem hiding this comment. FWIW: My initial thought would just be to have a get DatasetPage.getCvocManagedFields(DatasetField dsf) that would get called on line 160 and generate the serialized json for the data-cvoc-managedfields attribute. There shouldn't be any problem navigating from the dsf to the required values for the managed child fields in Java - I agree it would be hard to generate it in the JSF. How the SPA would assemble the info is tbd, but it seems like a cleaner solution to avoid extra hidden fields that have to be generated and that the Ontoportal JS has to go find. In any case, not too hard to add to the attribute at some point and deprecate the hidden fields if they are used in many scripts. |
||
| </ui:repeat> | ||
| <ui:fragment rendered="#{not compoundValuesstatus.last}"> | ||
| <br/> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested change: External Controlled Vocabulary scripts, configured via :CVocConf, can now access the values of managed fields as well as the term-uri-field for use in constructing the metadata view for a dataset.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested change accepted and commit