https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425
--- Comment #19 from Katrin Fischer <[email protected]> --- (In reply to Lucas Gass (lukeg) from comment #12) > (In reply to Roman Dolny from comment #8) > > There is also a suggestion in Bug 37995 (authority context, but similar to > > the application here) to avoid hard-coded names/identifiers/uri and > > introduce system preferences to make it more configurable and maintainable > > for libraries. > > Yes, I don't think these links should be hard coded. If this display needs > to be customized maybe it's a good use case for Bug 39860: > > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39860 I don't quite see the reason for the resistance here as it would only affect libraries with 024 in their data and we had a lot of requests about showing this kind of information (especially DOI) from our academics in the past. Passing structured data to XSLT is a pain and while bug 39860 is nice, it's still a barrier for a lot of libraries as it's too close to programming to be comfortable. I don't see how it would hurt to addd the most common $2 directly to the templates to avoid these issues and make it easier for libraries. For the URLs: I don't see the risk of them changing as a blocker, we have also a similar mechanism for OPACAuthorIdentifiersAndInformation and 024 from authority data. Since it's introduction there was neither a rush to add many additional codes nor a change in the URLs. We also added links there, because it improves the usefulness of seeing the identifiers immensely. I don't understand the push against a link since the source determines where it should link to rather clearly and it's an added benefit for the user. All the requests we had for DOI asked for a linked version. The info can also be easily hidden if we add individual CSS classes for each, would that be a good compromise? That said, I'd suggest some changes: 1) Patch currently doesn't apply and needs a rebase. 2) Check for existing 024 will add label if 024 exists in any case. + <xsl:if test="marc:datafield[@tag=024]"> This means the label will display when there is at least one 024, even if the code doesn't match any of the implemented ones. I think it might be easier to implement as individual label + code link pairs instead of a list under a shared label. with classes built from the $2 libraries could then also easily hide or customize entries individually. It would also be a litte more consistent with our current way of display. My local DOI snippet looks something like this: <!-- 024 - DOI --> <xsl:template name="doi"> <xsl:if test="marc:datafield[@tag=024]/marc:subfield[@code='2'][contains(.,'doi')]"> <span class="results_summary doi"> <span class="label">DOI: </span <xsl:for-each select="marc:datafield[@tag=024]/marc:subfield[@code='2'][contains(.,'doi')]"> <a> <xsl:attribute name="href">https://doi.org/<xsl:value-of select="../marc:subfield[@code='a']"/></xsl:attribute> <xsl:attribute name="target">_blank</xsl:attribute> <xsl:value-of select="../marc:subfield[@code='a']" /> </a> <xsl:choose><xsl:when test="position()=last()"><xsl:text></xsl:text></xsl:when><xsl:otherwise><span class="separator"> | </span></xsl:otherwise></xsl:choose> </xsl:for-each> </span> </xsl:if> </xsl:template> I am no longer sure why I used contains ... it's been a while. And the separator should be updated to use the new CSS solution :) -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
