https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26635 --- Comment #34 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Tomás Cohen Arazi from comment #33)
(In reply to Martin Renvoize from comment #32)
Hmmm, if that's the case I'm not sure I understand why there are tests for the search helper.. surely that will generally return multiple results?
I'm vaguely feeling like a single page web app would actually grab the full AV list when it first needs it and cache it locally to use for subsequent uses.. but as Koha isn't at that point yet we're unlikely to be able to really utilise that methodology..
If you need to render a list of (say) items, you will need to be able to make the GET /items call return not only the 'damaged' attribute, but also a way to return the linked AV, for rendering purposes.
The only thing that I'm not sure about this dev, is that (maybe) we want more fine-grained control of what objects should have their AVs expanded. For example, if we wanted the list of the items on a bib to display them grouped by the library they were checked out (I know, rare example heh):
GET /biblio/123 x-koha-av-expand: true x-koha-embed: items.checkouts
would mean we expand AVs for biblio, items, but also for the related checkouts (a probably expensive thing, as we don't have relationships in place for prefetching).
I would prefer a syntax that allows us to do:
GET /biblio/123 x-koha-embed: items+av,items.checkouts
Where will this be documented? I think the biggest weakness with our API is a derth of documentation for end users. We have some much great functionality that most API users don't even know exists let alone how to use it! This is a great example. I'd really love to see at a minimum, this be documented on a wiki page. We could start there, and perhaps build an API User's Handbook, or even just an API User's Cookbook just like the SQL Reports and Javscript library pages. -- You are receiving this mail because: You are watching all bug changes.