https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805

Michał <schodkowy.omegi...@icloud.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schodkowy.omegi-0r@icloud.c
                   |                            |om

--- Comment #15 from Michał <schodkowy.omegi...@icloud.com> ---
Okay I'll say something about my use-case and possible ways to support it
without allowing HTML, then also about Katrin's use-case.

Starting off with Katrin's use-case, I think actually the best solution would
be for Koha templates for a biblio page to have some kind of script block where
they'd set a global JS object with some extra metadata about the loaded up
record (as in API for example), possibly even its whole MARC-in-JSON
representation. This way any metadata would be accessible for whatever use-case
there was there. Also I currently load the MARC data with API in JS to access
extra metadata, so it'd let avoid doing that.

Also some way for templates to refer to any MARC field possibly with some
fallback (like mentioned XSLT) would probably satisfy some of the use-cases.

My use-case involves flexibility, such as:
- pulling some field out of MARC
- changing the URL depending on whether MARC field is there or not (for example
search by particular external control number or ID if it's there, otherwise
search by ISBN if it's there with another URL, and otherwise either completely
HIDE the link or fall back to title search for instance)

Currently I just do a fetch of MARC from API and then update the links
accordingly. If this was to be re-done to be a simpler field, it'd be nice to
have some kind of id="" or class="" on the links settable, so that these fields
can be referenced. Sure in worst case I could have a generic URL provided and
match with a selector of a[href='...'], but that's a bit uglier I think?

And having some metadata about biblio record in JS global object already would
let me avoid said API request. Similar to Koha.i18n object right now.

I could show my existing code when I'm at work again next week to maybe give a
better idea of how it looks like currently for me.

-- 
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
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/

Reply via email to