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 :
Thanks @ankitkumar for the great work that you are doing!
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?
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.
thanks for the suggestions @dkayiwa !!
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 ??
@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.
thanks @ssmusoke for the suggestions
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.
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.