After a series of various delays we finally have published Metadata Mapping Module 1.1.0-alpha1. It is available at http://mavenrepo.openmrs.org and https://modules.openmrs.org/#/show/82/metadatamapping. And why the alpha tag? Well, it’s just because I personally expect we might need to tweak the api a bit based on feedback.
So please give it a try. And remember: any feedback is good feedback.
@kosmik, thank you for leading the project and congrats on the release! I think we are ready to implement REST for the mapping functionality.
Since we bundle the webservices-rest module with a platform I think you can make the metadatamapping module require the webservices-rest module and implement REST resources in the metadatamapping module. I think we’ll want to expose MetadataSourceResource and MetadataTermMappingResource. Could you please create an issue for the work? Please see https://wiki.openmrs.org/display/docs/Adding+a+Web+Service+Step+by+Step+Guide+for+Module+Developers
I have managed to forget the REST api. I guess it would make sense to include the this in 1.1.0. The point of making an alpha release was to test and stabilize the module api before making a stable release and REST is basically just another “protocol” to access the same api.
In OpenMRS, is the REST api usually a 1-to-1 mapping to the Java service api or would the requirements of, say, client side view implementations need special attention?
OpenMRS REST resources are usually 1-to-1 mapping to the domain objects. Next we implement searches for resources using SearchHandlers to enable finding resources in a similar way our java services let them to be retrieved. Search handlers are optional, though very helpful.
OpenMRS REST API is general purpose and no particular client side view is being taken into consideration.
It’s been a while. I have taken advantage of the quiet period in the community’s interest towards Metadata Mapping Module and have taken a break myself.
So where are we? Earlier, we released the alpha version 1.1.0-alpha1 for people to try. It does not have a REST api which is still under way in MAP-8. I have not released the REST api yet as I’m still waiting for feedback.
So what next? Currently I feel I won’t be able to do any development work on the module before August. When I get back to work on the REST api, I can probably figure out all the technical details and write documentation and stuff but I would need feedback regarding the functional side of things. How does one use the module’s api? Another option would be that someone else takes over the responsibility of developing the module. Maybe someone with more time available or someone with more experience with OpenMRS.
Thanks @kosmik for staying positive even though it takes us that long to look at your work. I’m sorry about that.
I’ll review your pull request the first thing tomorrow and do some testing. Once we are done with that we’ll need to do a number of things to facilitate adoption.
Work on a simple UI to manage reference metadata mappings (supporting CRUD operations). Typically we would implement it using AngularJS + REST backend. Ideally using UI components from https://github.com/PawelGutkowski/openmrs-contrib-uicommons
Consider adding support for mappings to HTML Form Entry module so that you can start referencing metadata using mappings instead of their names or UUIDs in form’s html.
Is there any area which you would like to focus on first?
Thanks @raff! I will continue working on the pull request at the
beginning of August. At this point I can’t say much about the TODO items
you listed except that we need more people to work on these, I guess.
@raff just wondering if any work has been put into #2 above (Adding support for metadata mapping to Metadata Deploy Module).
We are looking to upgrade to the latest EMR API, and I’m starting to evaluate what changes would be required so that are current PIH EMR could support metadata mappings.
@raff i had earlier on reverted to first release a stable version of the module without these changes. So the commit you are pointing to is reverting the earlier revert. It therefore means we have the changes as intended.
The 2 commits show how to quickly migrate from GPs to mappings. There’s also a utility class, which assists with the above:
(not sure why it wasn’t used for those 2 commits)