[Koha-devel] API use in intranet and OPAC

Tue Oct 8 02:47:03 CEST 2019

Testing is always an interesting one. 

I’d say unit tests for the API functions and unit tests for the controller functions. You could mock the API for the latter. For integration tests, you could use selenium to test the integration between the two. Alternatively, manual integration tests. 

Personally, I’m hugely in favour of using the API for all business logic for OPAC functionality. The Koha OPAC could be a reference implementation and out-of-the-box solution, but then third party apps and library websites could opt out of using the Koha OPAC and instead just integrate with the API directly. I think a lot of my clients would actually prefer to integrate a Koha OPAC API into their own websites rather than using the Koha OPAC website. 

I suppose one downside could be the Koha OPAC website could become neglected, if everyone was just maintaining their own user interfaces. But I imagine a lot of people would still want to use the Koha OPAC website too. (After all, integrating with third-party APIs can be very challenging too!)

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

From: Arthur Suzuki <arthur.suzuki at biblibre.com> 
Sent: Tuesday, 8 October 2019 11:17 AM
To: koha-devel at lists.koha-community.org; dcook at prosentient.com.au; 'Katrin Fischer' <katrin.fischer.83 at web.de>
Subject: Re: [Koha-devel] API use in intranet and OPAC

One but not least issue with JavaScript, how do we test this?

I mean it's easy to test the API itself, making requests to it and monitoring the change in the koha db or mock objects.

It's also easy to check if the Intranet or Opac page returned by the server contains some strings in the html code (I guess, didn't try though).

How do we execute the Javascript in the test and verify it has the expected behavior?

Overall I have to say I'm very happy with this change (using more API) though, since it will raise interest for this further and can bring Koha to a whole new level within libraries app,
Koha being at the core of other third parties apps to interact with (not to mention them: Coral ERMS and Bokeh Library Frontend).
\o/

Le 8 octobre 2019 01:53:59 GMT+02:00, dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  a écrit :

I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs.

I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic. 

If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility. 

Just my 2 cents. 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

From: Koha-devel <koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of Katrin Fischer
Sent: Tuesday, 8 October 2019 7:31 AM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
Subject: Re: [Koha-devel] API use in intranet and OPAC

If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries.

Katrin

On 07.10.19 13:28, Kyle Hall wrote:

I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript.

---

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )

On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy at rijksmuseum.nl <mailto:M.de.Rooy at rijksmuseum.nl> > wrote:

Yeah I guess we reached the point that we just need javascript in OPAC ?

 <http://www.rijksmuseum.nl/> 

Museumstraat 1
Postbus 74888
1070 DN Amsterdam
 <http://www.rijksmuseum.nl/> Rijksmuseum.nl

Nu te zien:
 <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> Louise Bourgeois in de Rijksmuseumtuinen
 <https://www.rijksmuseum.nl/nl/nachtwacht> Operatie Nachtwacht

Verwacht:
 <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> Rembrandt-Velázquez. Nederlandse & Spaanse meesters

T/m 18 jaar gratis

 Please think before you print

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Arthur Suzuki
Développeur Support chez BibLibre
+33 6 37 94 13 53

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20191008/d17aa0e0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20191008/d17aa0e0/attachment-0001.sig>