IdentifierLinker: Mark the type of link

[maccabeelevine]

Use a data element to mark the type of link provided by the IdentifierLinker. Both BrowZine and Unpaywall provide at least two different types of links. It may be useful to hide (via css) a particular link type on some templates.

I.e. and example of custom CSS to hide BrowZine links that just point back to the link resolver:

.record-list.search-results-eds, .record.sourceEDS {
    .identifierLink[data-link-type="linkResolverOpenUrl"] {
        display: none;
    }
}

TODO

• Test Demo
• Test BrowZine
• Test Unpaywall

[maccabeelevine]

This could be either an alternative to #4774 or an additional mechanism.

• It's more flexible as it can apply to any IdentifierLinker (BrowZine, Unpaywall, etc.) and regardless of the identifier (DOI, ISSN, etc.). And depending on the CSS selectors used, it can be applied differently to individual pages.
• OTOH, in the use case where you want to disable a link type globally, BrowZine: Allow disabling individual bestIntegratorLink types #4774 is more efficient and (possibly) simpler to understand and implement.

[maccabeelevine]

I don't know how 'real' the demo driver output is supposed to be...can improve this if needed.

[demiankatz]

I don't think it needs to be very realistic, but maybe calling these foo-link-type and bar-link-type would make the context less ambiguous if we use this for testing. Having too many foo and bar values can make things ambiguous sometimes.

[maccabeelevine]

I have renamed this wrapper element class to plural identifierLinks because

1. It can contain any number of links (0-n) depending on what the data source returns
2. I need an actual wrapper element identifierLink for each of those links.

[maccabeelevine]

Wrapping the <a> in a <div>, we can remove the <br>. And so then hiding any individual identifierLink via CSS doesn't leave the whitespace.

[maccabeelevine]

Another option would have been to add the identifierLink class and linkType to the anchor element itself, and change its CSS display property from inline to block. But because it's an icon link it already has a custom display property. Seems safer to leave that alone.

[maccabeelevine]

This span-to-div change is not strictly necessary, but it was effectively a block-level element to begin with. So as long as I'm making various other potentially breaking changes to the templates and JS, may as well do this one.

[demiankatz]

Thanks, @maccabeelevine -- see below for some comments/suggestions.

I'm not too concerned about the breaking changes since this functionality hasn't been released yet -- but it would be good to wrap this up before the 11.0 release, or else we'll have to worry a little more carefully about BC issues.

[demiankatz]

I don't think it needs to be very realistic, but maybe calling these foo-link-type and bar-link-type would make the context less ambiguous if we use this for testing. Having too many foo and bar values can make things ambiguous sometimes.

[maccabeelevine]

I'm not too concerned about the breaking changes since this functionality hasn't been released yet -- but it would be good to wrap this up before the 11.0 release, or else we'll have to worry a little more carefully about BC issues.

Ok I forgot that IdentifierLinker itself is introduced in 11... this has been a very long release cycle. :) So yeah nothing really breaking here.

[demiankatz]

Thanks, @maccabeelevine!