Summary: | We need JavaScript equivalents to many of our TT plugins | ||
---|---|---|---|
Product: | Koha | Reporter: | Martin Renvoize (ashimema) <martin.renvoize> |
Component: | Templates | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, jonathan.druart |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26635 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22115 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 24455, 29575 | ||
Bug Blocks: |
Description
Martin Renvoize (ashimema)
2021-08-18 08:23:12 UTC
What do you mean by "javascript equivalent"? Using a REST API route? As in a nice simple way to construct display options from data returned from the API. Example, if we want to replace some of our data tables with Ajax equivalents using the API, for anything that includes Biblio title we can't easily replicate the structure returned by the biblio-title.inc template.. i.e a nice linked title consisting of multiple fields from the bib record. Yes, we can add a custom render function but we should keep it dry/reusable in the same way the template include is. Similarly, I'm not sure what route we've taken with regards av displays and the API. We return lots of codes.. is the intention to use embeds to get descriptions and even then, are we distinguishing between opac and staff and translations? Having a nice easy to call tender function that takes the code and converts it for display the way we have for TT would aid in the route to modernising the front end with load on demand and things. As in a nice simple way to construct display options from data returned from the API. Example, if we want to replace some of our data tables with Ajax equivalents using the API, for anything that includes Biblio title we can't easily replicate the structure returned by the biblio-title.inc template.. i.e a nice linked title consisting of multiple fields from the bib record. Yes, we can add a custom render function but we should keep it dry/reusable in the same way the template include is. Similarly, I'm not sure what route we've taken with regards av displays and the API. We return lots of codes.. is the intention to use embeds to get descriptions and even then, are we distinguishing between opac and staff and translations? Having a nice easy to call tender function that takes the code and converts it for display the way we have for TT would aid in the route to modernising the front end with load on demand and things. I've been thinking about this same topic for another project of mine. I actually ended up making specific DataTables controllers and had it send back descriptions instead of codes. (Of course, that through a little spanner in the search functionality, but it mostly works.) Which ones are missing still? Dependent bugs have been resolved. |