Burke and I have been pushing the idea that increased support for industry-standard technologies (rather than OpenMRS-custom approaches) is key to our community’s growth, and Burke has been bugging us to actually eat our own dog food on this.
In that spirit of, Wyclif and I spent a half-day pairing on implementing a Manage Encounter Types page in the adminui module, just using AngularJS and REST.
Here’s the code we wrote:
In the big picture, I’d ask the dev community to please start paying more attention to the REST Web Services module. We have 3 tickets waiting for initial code review, 16 tickets Ready For Work, and 40 in Needs Assessment!
Here are some particular issues that came up, particularly around REST:
RESTWS-456 You cannot unretire metadata via REST. Lluis had done a PR for this in March, but nobody reviewed that until Wyclif and I saw it a couple days ago.
You can’t just GET a REST resource, edit a field, and POST it back. RESTWS-460 (In practice I’m not sure that we really want to implement this without also having the resources include a version stamp, so we avoid re-posting stale objects.)
And here are some general To Dos we noted:
There should be a standard (global?) way of handling failed REST calls (e.g. devs are going to naturally write, in their Angular code: doRestCall().then(function() { /* success */ }), but we should either give them a standardFailureHandler function, or else decorate the $http service with some standard behavior.
Our REST API enforces a maximum page size, so naively doing the REST GET for /encountertype may not give you all the encounter types => we need a standard practice (and JS helper) that gives you a fancy object that has all results so far, a status saying if there are more results, a getAllPages() function, etc.
We should also have some helper functions to help you work around some existing limitations in our REST module, e.g. this issue
Thanks Darius for sharing this with the community, i think we need to make a push to get some of these issues addressed sooner that later, probably we can have a design call in the near future and discuss how to implement the general TODOs you mentioned.
@darius does this need 60 min or less? It sounds like this conversation needs to happen soon and we have some items scheduled for the next few weeks. @burke is there something you feel could be pushed out to 29 June so we can have the “Standard JS tools for REST” conversation sooner rather than later?
15 - Condition List: Talk w/ Bahmni BA about use cases and requirements
17 - Web Framework: create a list of goals for the few months & Deciding what Order Entry functionality to harvest from the PIH visit note to the reference application w/ Darius (15 min)
Not sure where it ranks. @burke do you have any thoughts on this? I believe on yesterday’s PM call though we decided to discuss how to make REST services more robust on this Wednesday’s design forum.
I must add that @sandeepraparthi in his GSoC project is making HTML components for the refapp UI that also need these JS Tools for REST. I was asking him to write some for the OWA work that he is doing, but if this happens outside, then it will likely save him some work and be able to use these. The design call might give him good idea of the contract for these REST methods…
Tomorrow on the design forum we will use the topic of “Web Framework:
create a list of goals for the few months” to talk about REST and JS Tools.
@sunbiz and @sandeepraparthi should join if they’re available.
We can decide where to go from there at the end of the call.
Thanks @sunbiz@darius I would love to Join the design Forum since as my mentor stated would help me
get some idea about the JS tools for REST as well see how can i can contribute to REST if needed now or after GSoC
