https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39509
--- Comment #3 from David Cook <[email protected]> --- (In reply to Lisette Scheer from comment #2) > Sure, cascading XSLT works where there's more files for the different > definitions, and you can create a custom one that overrides the default but > it's still there. This means when there are updates the default is updated > but the custom is still there. > > This also makes it easier to debug and make changes to the XSLT. > > Also if you change something it only breaks that section and is easy to > recover the default. I'm not sure that I follow. Is the idea that there are multiple XSLTs in a pipeline which are each applied to the XML sequentially? Or the custom XSLT is imported into the 1 XSLT and it overrides the existing templates? Or something else? > We were discussing yesterday during Hackfest the difficulties with > customizing record display when libraries have different needs. Personally, I think that the XSLT for record display is a dead-end, especially in light of things emerging metadata schemas like BIBFRAME. I think we should be looking at using the Elasticsearch JSON document and using a template language for display (whether that's server-side or client-side). Provided we restrict the security of the template (ie disabling EVAL_PERL/ABSOLUTE for Template::Toolkit for instance) and use Content-Security-Policy, we could actually let libraries modify these templates via the Web UI. This is a strategy that I've employed in discovery systems. That said, we would still run into that same problem of new updates to displays not flowing through to customized displays. But we could mitigate that just by flipping a flag at upgrade time which could show a dismissable message saying "hey the default template has been updated - consider reviewing your custom template view" or something like that. -- You are receiving this mail because: You are the assignee for the bug. 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/
