@pascal Do we need both of these headers because it doesn’t look good ? The first is the one which takes the app name “demo” from the main.js and second one is the header I used from the uicommons library.
Use the second one.
1 Like
@raff Hii
I have some minor issues while running tests with jasmine and karma.
- I am getting below “transition superseded” error while using angular 1.6 and above but all the tests passes when I change all the angular dependencies to angular 1.5.5 and above. why it is so?
- While using the angular 1.5 series dependencies (which is working for me), I placed all the required dependencies in the package.json file and tried running “npm install” command. But its not working. I have to manually install all the dependencies by running “–save” and “–save-dev” commands each time.
Do you have any idea what could be the possible reasons for these ?
Edit : I have already tried completely uninstalling the node and re installing the latest version and also tried changing the angular-ui-router versions. But nothing solved it
This is because you are not specifying the version explicitly:
Note the ^ character. Make sure you understand the dependency versioning scheme.
That said, I think we should try to get things working with the latest version of AngularJS and not force developers to stick with 1.5.
Thanks @pascal 
learnt a new thing !!
Yes, I am trying to find some way to make it work with the latest angular dependencies !!
1 Like
@ankitkumar, have you seen this project?
@raff, do you think we should include this in the scaffolding provided by the OWA generator?
I had a quick look at this repo. There are two things to be noted here :
- This library is not included in the node_modules, so to use that we will have to manually download and include that
- There are two modules present there. One is openmrsRest which is almost same as that of the uicommons library if I am not wrong (except the function which is fetching the serverUrl) and we have already used the functions from openmrsRest component in our new component. The second one is the openmrs Translate which we have used from the uicommons library but this translate module contains some additional functions too. So, we could think of using it instead of what we have already used. But its also not in the form of reusable components and also don’t have any HTML attached to it. Still we could think about some way of using it if @raff thinks we should use it !!
So the following instructions in the README are not working?
npm install @openmrs/angularjs-openmrs-api --save
Yes, I think this library is an AngularJS API built on top of openmrsRest.
Right, I still think our reusable components are useful, but if OpenMRS is creating an “official” AngularJS API, then we should probably use that in our components.
npm install @openmrs/angularjs-openmrs-api --save
Oh I haven’t seen that ! Yes this will work in case we will be using that !
Till we get some views on this API, we can discuss about the use of FHIR module in our generator. I have some thoughts about it.
As you mentioned in the comments on the proposal that we need some easy way to use the FHIR module. So, what I am thinking is we can design a new FHIR component where we will be fetching the server context or url and then design some small functions there (for create, delete, etc) so that any user using that could use the desired functions from there to perform their required operations whether they will be using openmrs SDK or standalone. After that, we can include a demo having a short form to show how to use it to create a new patient.
Could you feel it good ?
@raff Hii 
Could we have your valuable views on using “openmrs-web-angularjs-api” (as discussed above), if you have some spare time ?
This sounds good to me.
1 Like
Hii
I have one doubt in my mind regarding introducing the openmrs FHIR module support and that is do we really need to support the FHIR module because we can perform all the CRUD operations easily using the REST API. And in my opinion, if REST API’s are being widely used instead of the FHIR module, then we should also give support to the REST API rather than the FHIR module for creating patients or persons. In openmrs-standalone also, by default we get the REST module not the FHIR module. So, what do you think about it. Do you have something specific in mind regarding the use of FHIR module or you are equally fine with the use of REST modules for the CRUD operations ?
Thanks, Ankit kumar
1 Like
Congrats @ankitkumar
A new version (v0.5.0) of the OWA generator has been published with shiny 
new OpenMRS Angular Components & testing infrastructure. Give it a try today 
.
Regarding next steps for the generator, my initial thought was to try and generate an example that uses FHIR. My rationale was that this would enable developers who know FHIR (but not necessarily the OpenMRS API) to get up and running quickly with app development.
I remember some initial resistance this idea, so I think we should open up the discussion to the community. Perhaps some of the @dev5 team have some ideas? If we don’t get a response here, then I think it’s worth starting a new thread for feature requests.
Edit: Original project page here.
1 Like
Thanks and congrats to you too @pascal 
Ok, I will open up a discussion for that !!
Okay, hopefully we get some response. One idea might be to have an Angular 4 scaffolding option.
1 Like
yes that might be a great idea !!
Discussion for the FHIR module support : Next Steps For OpenMRS OWA Generator ✨
PR for the patient create component (along with the person create feature) with detailed description : https://github.com/psbrandt/generator-openmrs-owa/pull/31
Any suggestions / comments will be appreciable !!