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.

Sign up for GitHub

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

CVOC : Adding hidden metadata fields (Ontoportal integration) #10503

Merged
merged 5 commits into from
Jun 24, 2024
Merged

CVOC : Adding hidden metadata fields (Ontoportal integration) #10503

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1b25439
Add hidden metadata fields for cvoc JS
jeromeroucou Apr 17, 2024
ec995e4
adding release note
luddaniel Apr 18, 2024
f0aff2d
Accept review suggestion on documentation
jeromeroucou Apr 24, 2024
a1804a3
CVOC: fix typo to have "data-cvoc-managedfields" on dataset page visu…
jeromeroucou Apr 29, 2024
525ad0d
Add cvoc index to identity bloc metadata
jeromeroucou May 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions doc/release-notes/10503-cvoc-hidden-html-fields.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
## Release Highlights

### Updates on Support for External Vocabulary Services

#### Hidden HTML Fields

External Controlled Vocabulary scripts, configured via [:CVocConf](https://guides.dataverse.org/en/6.3/installation/config.html#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.

Those values are hidden and can be found with the html attribute `data-cvoc-metadata-name`.

For more information, see [#10503](https://github.com/IQSS/dataverse/pull/10503).
25 changes: 19 additions & 6 deletions src/main/webapp/metadataFragment.xhtml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,7 @@
<f:passThroughAttribute name="lang" value="#{DatasetPage.getFieldLanguage(cvocConf.get(dsf.datasetFieldType.id).getString('languages'))}" />
<f:passThroughAttribute name="data-cvoc-service-url" value="#{cvocConf.get(dsf.datasetFieldType.id).getString('cvoc-url','')}" />
<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()}" />
<f:passThroughAttribute name="data-cvoc-managedfields" value="#{cvocConf.get(dsf.datasetFieldType.id).get('managed-fields').toString()}" />
</h:outputText>
<h:outputText value="#{dsf.getDisplayValue(mdLangCode)}"
rendered="#{!dsf.datasetFieldType.allowMultiples and !cvocOnDsf}"
Expand All @@ -101,7 +101,7 @@
<f:passThroughAttribute name="lang" value="#{DatasetPage.getFieldLanguage(cvocConf.get(dsf.datasetFieldType.id).getString('languages'))}" />
<f:passThroughAttribute name="data-cvoc-service-url" value="#{cvocConf.get(dsf.datasetFieldType.id).getString('cvoc-url','')}" />
<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()}" />
<f:passThroughAttribute name="data-cvoc-managedfields" value="#{cvocConf.get(dsf.datasetFieldType.id).get('managed-fields').toString()}" />
</h:outputText>
</ui:repeat>
<ui:repeat value="#{dsf.getValues(mdLangCode)}" var="value" varStatus="loop" rendered="#{dsf.datasetFieldType.allowMultiples and !cvocOnDsf}">
Expand All @@ -123,7 +123,7 @@
</div>
</ui:fragment>

<ui:repeat value="#{dsf.datasetFieldCompoundValues}" var="compoundValue" varStatus="compoundValuesstatus">
<ui:repeat value="#{dsf.datasetFieldCompoundValues}" var="compoundValue" varStatus="compoundValuesStatus">

<ui:repeat value="#{compoundValue.displayValueMap.entrySet().toArray()}" var="cvPart" varStatus="partStatus">
<c:set var="cvocOnCvPart" value="#{cvocConf.containsKey(cvPart.key.datasetFieldType.id)}"/>
Expand All @@ -148,7 +148,8 @@
<f:passThroughAttribute name="data-cvoc-service-url" value="#{cvocConf.get(cvPart.key.datasetFieldType.id).getString('cvoc-url','')}" />
<f:passThroughAttribute name="data-cvoc-protocol" value="#{cvocConf.get(cvPart.key.datasetFieldType.id).getString('protocol','')}" />
<!-- unlikely to be used in this case -->
<f:passThroughAttribute name="data-cvoc-managedfields" value="#{cvocConf.get(cvPart.key.datasetFieldType.id).get('managedfields').toString()}" />
<f:passThroughAttribute name="data-cvoc-managedfields" value="#{cvocConf.get(cvPart.key.datasetFieldType.id).get('managed-fields').toString()}" />
<f:passThroughAttribute name="data-cvoc-index" value="#{compoundValuesStatus.index}" />
</h:outputText>
<!-- Cvoc on parent field -->
<h:outputText value="#{cvPart.key.value}"
Expand All @@ -157,10 +158,22 @@
<f:passThroughAttribute name="lang" value="#{DatasetPage.getFieldLanguage(cvocConf.get(dsf.datasetFieldType.id).getString('languages'))}" />
<f:passThroughAttribute name="data-cvoc-service-url" value="#{cvocConf.get(dsf.datasetFieldType.id).getString('cvoc-url','')}" />
<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()}" />
<f:passThroughAttribute name="data-cvoc-managedfields" value="#{cvocConf.get(dsf.datasetFieldType.id).get('managed-fields').toString()}" />
<f:passThroughAttribute name="data-cvoc-index" value="#{compoundValuesStatus.index}" />
</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}" />
<f:passThroughAttribute name="data-cvoc-index" value="#{compoundValuesStatus.index}" />
</h:outputText>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @qqmyers , we discussed with @jeromeroucou to understand the depth of your point, here are our views :

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}">
<ui:fragment rendered="#{not compoundValuesStatus.last}">
<br/>
</ui:fragment>
</ui:repeat>
Expand Down