https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38677
--- Comment #4 from David Cook <[email protected]> --- (In reply to Nick Clemens (kidclamp) from comment #3) > I'm not sure I understand the concern here, can you explain what the > implications might be? The concern would be in terms of UX. The scenario would be a library checks every MARC field they think that could be remotely useful, checks the display for 1 record, but misses a bunch of other records that now have overcrowded displays that aren't useful to end users. (I'm also thinking about overlap between chosen fields and ones that already exist in the XSLT.) I can already imagine needing to routinely pare back the options that people have chosen. That said, there are times where it would be nice to let a library add the display of some fields that they use that no other library uses. Maybe I'm just being too pessimistic. > > From a technical standpoint, we wouldn't necessarily have to build/update > > the XSLT. Rather, using XML::LibXSLT->register_function(), we could > > introduce a Perl function to the XSLT to tell us whether or not to render a > > particular field/subfield combination. (I do this all the time in our local > > Koha and in Koha plugins.) > > If you have an example or two of what you do here, that would be interesting Here's an example from a plugin. This is in the .pm code (declared near the top of the .pm file as it's a class function we want run at load time): XML::LibXSLT->register_function("http://www.prosentient.com.au/xsltperl/jats","validate_isbn",\&_validate_isbn); sub _validate_isbn { my ($input) = @_; my $rv = XML::LibXML::Boolean->False; if ($input){ eval { my $isbn = Business::ISBN->new($input); if ($isbn && $isbn->is_valid){ $rv = XML::LibXML::Boolean->True; } }; if ($@){ warn $@; } } return $rv; } Then in the XSLT in the xsl:stylesheet element, I add: xmlns:pro="http://www.prosentient.com.au/xsltperl/jats"; And in the body of the XSLT: <xsl:if test="pro:validate_isbn(marc:datafield[@tag='020'][1]/marc:subfield[@code='a'][1])"> <!-- Do stuff! --> </xsl:if> The main limit is our imaginations here. Also, keep in mind that Koha::XSLT::Base allows us to pass "parameters" to the transform() functions. While I initially thought about that in terms of passing a string which could be manipulated, it is XPath, so it could be easy to generate some XPath in Koha that lists all the extra fields/subfields that we want to display, and then use that for selecting within the XSLT. Lots of options there using existing functionality available to us. > It may be XSLT is not the best tool for what we want. We have largely > stopped using custom XSLT in favor of using the API to pull extra fields > from the MARC. Users with custom XSLT don't get any Koha enhancements that > use the XSLT until an upgrade, and the process of rebasing XSLT can be quite > tedious. Rebasing XSLT is one of my least favourite activities in work life. Using the API is a good plan. It's much more in the vein of what we're trying to do overall with Koha I reckon. > I think one of the things we really want from this is, users should be able > to easily control which fields are displayed, without a great amount of > technical knowledge. We find XSLT is a bit of a high bar, a bit too easy to > make one change, and break the entire display :-) Generally speaking, I'm in favour of giving power to the people... except where it creates more issues than it reduces. I think I'd be much more in favour of this, if we had a way of controlling how much space the fields take up. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ 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/
