New AngularJS Components for OpenMRS

I am currently working to design new user friendly components for the OWA Generator so the user scaffolding a web app through this generator can easily reuse/access these components without putting extra efforts in engaging themselves much in understanding the openmrs oriented approach of developing components. So, I am looking for some suggestions from the community members regarding which components can be valuable to implement. I have already created a patient search component which looks like this :

Still more work to be done on this patient search component (any suggestions will be appreciable) !

Other than that, I have used the openmrs-contrib-uicommons library to introduce some of the components. So, basically we already have :

breadcrumbs component :

notification component :

which shows a toast like this :

translate component :

which translate a specific text in the language specified (as above) !!

Apart from all these components, I would like to know that which components would be more valuable to implement !! I will be eagerly waiting for the responses !! :slight_smile:

Ref : @pascal @darius @raff @dkayiwa

Thanks, Ankit kumar (working on OWA generator improvement project)


Great work! Are you blogging this?

1 Like

thanks @r0bby, yes I will be blogging it in my this week’s blog post !

1 Like

Thanks @ankitkumar for the great work that you are doing! :smile:

Is the patient search widget configurable? For instance, can i determine the fields to display? How many records to display on each page? I could think of a few others like Observation, Encounter, and Provider search widgets.

@suthagar23 do you have any widgets which you think would be useful for your project?

1 Like

Sorry to crash this party late, but one of the things we are looking into is how to leverage Twitter Bootstrap to provide basic components that are tested and used widely to lower the learning curve for developers coming from a general web development background.

My worry about the components being developed here is that they are openmrs specific which increases the learning curve.

Is it possible to look at bootstrap and angular integration so that any new components are more general from external libraries than building OpenMRS specific ones which have to be maintained with non-existent resources.


@ssmusoke when you say that you worry about these components being openmrs specific, are you looking for components to be used in non openmrs projects? :smile:

Yah @dkayiwa. I have done some other widgets manually, that are

  1. Modals( like Bootstrap Modal)
  2. Loading POP Up - which can disable the page while loading and able to show the Loading Image
  3. Better to implement search as long text box with search Icon
  4. Panels with Headers (Like Bootstrap Panel)
  5. Tooltip (not like a common tooltip, better have some better GUI)

Those are will help to create a GUI better!

thanks for the suggestions @dkayiwa !! :slight_smile: No, the search box is not configurable yet. And there is no limit on the records to be displayed. I have made a scrollable separate div box which displays all the results related to the search text. Till now, it only works with the patient’s name only and I am now planning to provide it the functionality to search using the patient identifier also. So, should i work to make it configurable ? I have an idea for that. I can provide some check boxes (with patient attributes) and the user can then mark the check box as per their needs i.e whichever attributes they want to see. How about that ??

I was just throwing in ideas. Feel free to make the final decision with your mentor. :slight_smile:

@dkayiwa Our sanity check would be, can a web developer use these components without having to learn openmrs-specific syntax? Why build widgets that already exist else where - our resources are better invested integrating with existing tools.

Unless i got him wrong, my understanding was that he was simply using widgets that exist out there to combine them into openmrs specific widgets that can be reused. For instance, if i need patient search functionality, i do not need to know details of how i would do this using the generic widgets out there to add openmrs specific patient search functionality. Putting it in another way, i do not need to go through the pain that he has, to come up with this functionality. :slight_smile:

thanks @ssmusoke for the suggestions :slight_smile: I respect yr thoughts and I totally understood what you are trying to portray !
But my point is if in case any user/developer who is trying to develop or generate a webapp, most probably he/she would try to make a rest call (according to their needs). So, in order to make rest calls through the webapp, they must know how to use the openmrsRest module which is present in the ui-commons library. If he/she doesn’t even make efforts to just learn how to use openmrsRest module, then they may have to go through a long process of making rest calls by themselves (which would increase their learning curve again)

So, what I am doing here is, except few components which are used from the uicommons library, I am developing new components with Angular best practices which will use openmrsRest module for rest calls (the only openmrs specific approach they need to learn). So, they don’t have to bother much about the logic behind the component and they should just have a brief idea about how rest module works.

And you are right for the components which are used from the uicommons library that they need an openmrs specific approach to be implemented. But, integrating it in the generator will enable them (users) to use those components without pain (as @dkayiwa has already mentioned in the previous comment) because they just have to make the html tag of the component name they want to use and then they can focus on whatever they want to program in that webapp ( as I don’t think that anybody would use the openmrs owa generator to generate webapps for purposes other than to be used at openmrs )

or is it the thing that this generator is to be used for non - openmrs projects also ?? if this is the thing, then I guess my perception was wrong for this project !!

@ankitkumar We are looking to bring more developers who do not have OpenMRS experience, and they should not in order to interact with the REST API.

However some advice from my experience, is that it is very easy to build something, but difficult to maintain it… I would rather leverage work done by others before I write a single line of code that I have to test, debug, and maintain.

1 Like

@ssmusoke i could be missing something from your communication. So let me put it this way in order to understand you.

We have a number of use cases where one is building something that needs patient search functionality. To give an example, when one is trying to fill an form, i need a patient search widget as you can see this:

And what @ankitkumar is doing is that instead of having to build that widget myself, he gives me one which i can simply use by including one line in my page. Don’t you think that greatly improves my productivity by not having to get involved in the details of how to build such a widget or functionality?

@dkayiwa I am looking at the components in the message above - which are basic building blocks. However like i apologized in my first post i am coming late to the party, and giving advice towards a direction I think we should go.

Rather than basing of Bootstrap I think it makes more sense to integrate bootstrap for Angular so that we have all available foundation widgets, then build search patient etc widgets on a stronger foundation that is widely supported and can be upgraded.

1 Like

@ankitkumar as you get along, you may find this helpful:

thanks @dkayiwa, but are you having such ui-component-design reference for angularjs ?? I am working on Angularjs.

Am not specifically referring to React components, but rather the design principle. :slight_smile:

Oh …OK. I will go through that !! :slight_smile:

Here, actually what I didn’t think about the basic components, For an Example If he designs the Patient Search component then, there should be some better implements such as

  1. Patient Search with Modals, then User can easily search the patients without moving to other pages.
  2. Loading POP Up/Loading when REST Connection is working for a long time
  3. Long length Search Box (usually we apps will be like this - equal to the bottom table width)
  4. If better implement tooltips for the actions also.

If those features are implemented in the built-in component, then that will very effective for the usage.