One of the simplest script in Koha is admin/cities.pl. There is no relationship, very few columns, etc. The script has been rewritten recently (bug 14888) to use Koha::Object[s]. It has been cleaned and is a good candidate to collect the different point of views/implementations possible to use the REST API (bug 13799).
Created attachment 43194 [details] [review] Bug 14974: Joubu's try to use the REST API for cities Here's my try. The naive way is to do AJAX calls and redirect to the list after delete/update/add. The main issue is that it does not simplify the code so far... Question: How to display notif to the user after actions (delete/update/add)? How to simplify the swagger file? How to present a search interface? See other comments in the code.
I would be happy to see a try using AngularJS.
Hi everyone (ccing some people who could be interested in this discussion), Bug 13799 is going to pass the QA step. I think we need to know where we are going and what is the next step. Beside the authentication problem, how could we use the REST API from Koha scripts? I have submitted my naive implementation (see above), but it's not so nice and would like to see what you have in mind. We need to have good basis, write guidelines and impose them, before pushing any patches, IMO. What is suggested on bug 13799 is too light and need a framework to be used efficiently.
(In reply to Jonathan Druart from comment #2) > I would be happy to see a try using AngularJS. Looks good! I've *love* to see an Angular implementation! I think as a best practice we should build our interfaces so they can interact with Angular's $resource service factory with no customization wherever possible ( see http://www.sitepoint.com/creating-crud-app-minutes-angulars-resource/ for example ).
I've posted a followup to the main api bug to showcase using $ref's to split up the specification file, that 'should' help with that side of things a bit. UI wise, I agree we need a good example implementation an I think AngularJS would be a great one to showcase here too. I'm not entirely sure that $resource is still the way to go with angular now, I've asked a colleague (whose spent the best part of the last year shoulder deep in angular) to come in and comment on angular best practice to help guide us.
Hi all My first posting to the Koha community, exciting stuff! :) As Martin mentioned, I've been working with Angular for about a year, so I'm by no means an expert (Angular is a big beastie), I've got a good feel for ways to do things and how Angular "works". The $resource service is a nice wrapper around the $http service and enables you to create API resource objects that can be interacted with in the traditional CRUD methods. If you're starting from scratch and looking for a consistent way of accessing API resources then it's a good way to go. Although I'm up to my eyeballs at the moment (aren't we all), I'd be happy to offer any guidance if it's all needed. Cheers Andrew ------ Andrew Isherwood Software Developer PTFS Europe Limited Content Management and Library Solutions +44 (0) 20 8123 4257 email: andrew.isherwood@ptfs-europe.com skype: andrewisherwood.ptfseurope web: http://www.ptfs-europe.com/
Thanks for your input Andrew! I'm sure any guidance and guidelines you may suggest would be greatly appreciated!
Created attachment 50022 [details] [review] Bug 14974: Try to make benefit from using the API Previous patch immediately redirect after each action (add/edit/delete) so there is no real benefit from using the API. This patch move the add/edit form into a modal window, and redraw the table after each action, so the page is never reloaded. It also adds a messages area to put messages in (after success/error)
No AngularJS/SomethingElseJS proposal so far, so I suggest we move forward with this. Changing status to Needs signoff to have more opinions
Facebook uses Flux. That is interesting and very lightweight. AngularJS is big and needs non-standard html element attributes. I would prefer to not have non-standard html attributes or even data-* attributes unless necessary. Also worried about AngularJS being too one-minded in how to do things. That can be a good thing as well. Especially for a project like Koha where we have a lot of developers from around the world doing things their way. Having a good formal development pattern helps a lot. I am 40% for AngularJS, maybe even 50% if I look really hard :) I think most of the guys feeling for REST API and javascript frameworks are here, so I think it s safe to ask how do you feel about AngularJS?
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/cities.tt CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/admin/cities.tt Auto-merging api/v1/swagger.json Failed to merge in the changes
Resetting assignee to default as I have already submitted my try.
(In reply to Jonathan Druart from comment #12) > Resetting assignee to default as I have already submitted my try. Good :) Don't burnout yourself with incessant rebasing. patch applier should be able to do basic merging
(In reply to Jonathan Druart from comment #12) > Resetting assignee to default as I have already submitted my try. Jonathan, do u allow me to split this into * REST API endpoint for handling cities * Use cities endpoint for CRUD Maybe that's the way to do it so it is simpler to achieve.
(In reply to Tomás Cohen Arazi from comment #14) > (In reply to Jonathan Druart from comment #12) > > Resetting assignee to default as I have already submitted my try. > > Jonathan, do u allow me to split this into > * REST API endpoint for handling cities > * Use cities endpoint for CRUD > > Maybe that's the way to do it so it is simpler to achieve. Yes of course.
Is Kyle planning to submit his ReactJS alternative to here or is that going elsewhere? I'm looking forward to seeing the alternative in code :)
In addition to Martin's previous comment, have any reference libraries / functions been created in order to actually make the API calls and work with the response? As part of our in-progress stock rotation feature we're intending using AJAX & the REST API to simplify one particular function. Martin is working on the endpoint, I'm doing the front-end, but don't want to roll my own calling functions if there is an intention to have a standardised way of doing it. Cheers! Andrew
Dream became true in Bug 25279 *** This bug has been marked as a duplicate of bug 25279 ***
(In reply to Fridolin Somers from comment #18) > Dream became true in Bug 25279 Well, not really. The idea here was to use the different REST API routes for all CRUD operations, not only list.
Bug 30160 is going to provide an alternative using React.