https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37573
--- Comment #13 from Michał <schodkowy.omegi...@icloud.com> --- > It's a work in progress, but believe me when I say it's coming. And rightly so, I fully support it. > I think there's some merit to what you're saying there. In fact, I think that > there's an argument to be made for removing the removal of unsupported tokens > completely, since it's not really necessary. (We could add the supported > tokens to the syspref description and then any unsupported tokens are the > library's responsibility to remove.) True, I think it wasn't too thoroughly thought out to begin with. For example it could obfuscate a typo by making someone thing that for example just this particular biblio they tested with resolves to empty string for that token... > But your change here would also stop many potential tokens from being > removed, which some could say is a regression of the current behaviour. I think this is only in a very specific situation, say if some library added a new token that did not adhere to the naming convention and then forget to re-introduce the change after upgrade. I think that'd very specific conditions. On the contrary, getting rid of unrecognized token removal completely would have much more chances percentage-wise of causing broken links for non-existent tokens that someone made up or made a typo etc. In theory both scenarios are wrongful, but I think non-existent token look-alikes are more likely to emerge somewhere... But I'd personally be completely fine with either of the paths tbh. > I'd advise against that coding as well. You'd be better off with > data-something="1" "data-somethingelse="2". Fair, I'd do something like that myself probably too in practice (multiple attribs over JSON), but I know that such JSON attributes are a very common practice in some places. So I could imagine someone inserting a link with some attributes and then loading some script of some external provider that'd find an element, data in it, and turn it into a proper link or something technically. > Plus that's a pretty strange use-case for OPACSearchForTitleIn. Keep in mind > too bug 36805 which would proably also make that impossible. I don't think it's overall too strange other than the chosen method of grabbing element by using a script and then calling a func. Thing is, I believe it's the most elegant given that for OPACUserJS things like when that script is executed and whether it's gonna change between versions are less guaranteed probably. Plus if whole scripts to create the URLs were put in there, it'd make things less scattered around. But I could probably end up achieving the same stuff by just using a special id="" or class="" and it would be no trouble in practice, so there's that. But yeah I'll definitely have to chip in some concerns about bug 36805, so that such use-cases are preserved, I see I'm not the only one. The existing tokens only allow some very specific fields to be used. And even if they allowed full MARC access, that's not enough. For example what if I want to search in external catalogue by given ID if it's provided, but fall back to ISBN search otherwise, but also maybe fall back to title search or hide the link as last resort? Simple fallback wouldn't suffice, the URL for different search would be different etc. But with free HTML it's very simple stuff, few lines of code and one can get perfect links. (whether that code be here or in OPACUserJs eventually) > I think that's debateable, but tell you what... I'll reset this to "Signed > Off". I am going to change the title and release notes to reflect the actual > change made. Thanks. > And yes CSP is coming too, so as per above... use OpacUserJS for injecting > Javascript. Otherwise, you're just going to have to change your code later. > May as well future-proof yourself a bit now. Meh, I kinda could, but I'll wait for now. Current solution already works, and future-proof is not a guarantee if some other miniscule things change like that place of execution I mentioned above or depending how the aforementioned bug goes forward. But when inevitable comes, I'm happy to oblige, it won't be too hard to fix it up then. -- 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/
