@sunbiz This thread is for discussions related to OWA Store Project.
Related links: Bintray: Better method of distributing apps? The future of Modulus Previous discussion
2 Likes
@sunbiz So far the objectives are
There are many JS frameworks with their own advantages and disadvantages,so which JS framework would be suitable for our requirements?
Most people in the OpenMRS community are currently using Angular 1.x, so in order to increase the number of potential contributors/maintainers, I would recommend using that.
1 Like
How about using Angular Bootstrap or Angular Material for UI components ?
1 Like
Personally I think it’s worth considering other frameworks (not Angular 1.x) for a completely new codebase. (Across ThoughtWorks’s broad experience, the current preference is React > Ember > Angular.)
(But Pascal is correct that the OpenMRS community has the most experience with Angular 1.x.)
It definitely makes sense to use a UI component library. Having used angular-ui-bootstrap in openmrs-module-uicommons, it’s okay, but I don’t love it. So Angular Material looks promising.
2 Likes
If it were my personal project, I’d definitely be using React/Redux scaffolded using [react-boilerplate v3.0.0] (https://github.com/mxstbr/react-boilerplate/tree/v3.0.0) and styled with material. I just don’t want the same thing to happen that happened to Modulus, so we should do what we can to maximise potential contributors/maintainers.
Also, if the app store is going to be accessible from within OpenMRS, then it should probably be styled using ui-commons.
1 Like
I think we should not use any framework for what we are building. Use plain HTML with JavaScript code. The codebase will not be huge and I dont see any benefit of using AngularJS, React or another framework. It just makes a more complex codebase, for no apparent gain. If its planned to be light and thin, then keep it light and thin!!
I disagree. Material design is good here – at least use that. Why not use a framework – I do not think it will add complexity, not using one and rolling our own will make it even more complex? It should have some link to Modulus as well.
I haven’t been following exactly what this module needs to do, but, per @lluismf great post, if it’s simple enough that it can be done just with JQuery, I’d use that. If it’s not simple enough, could it be made simple enough to only use JQuery?
To add a little history of Modulus, remember there was a module repo before Modulus–and it wasn’t as modern or sleek as Modulus, but it was stable and it worked.
But I’d agree with Robby that you find yourself slipping toward rolling your own, definitely use an existing framework instead. I’ll avoid the debate as to which one. 
Mark
@mogoodrich This project aims at developing a frontend to use the rest api exposed by bintray where our omod’s and owa’s will be hosted.
Material design has nothing to do with a framework. I think we should use material design. A library is different from a framework. JQuery is very good library for dealing with DOM and REST, at least for what I see is needed in this project. AngularJS or React or whatever framework that needs any learning curve beyond what is obvious seems to be like a bad idea.
Actually it was Saptarshi’s suggestion (I just added the comic strip)
I agree, if the student has no previous experience with the framework he can spend the whole summer learning it. It’s an obvious risk.
It’s ultimately up @sunbiz how the project goes – so long as it’s lightweight – I’m happy 
1 Like
As I am trying to access Bintray’s resources(api.bintray.com) from my local server (localhost:8080) my requests are being blocked because of Same-origin policy.
The remedy is to specify some header like “Access-Control-Allow-Origin: true” in the response from Bintray server to all the requests made from our domain.
So should I communicate with Bintray devs, to allow requests made from my domain ? (or) Is there any other way ?
References: http://stackoverflow.com/a/19821851/5229767
Please correct me if I am wrong.
Since they require authentication for any API access I think you should be sending queries to api.bintray.com from your server and not from a script in a browser. When you get response from api.bintray.com you can process it on the server or forward the response directly to a browser. You should not disclose any authentication details you use to access api.bintray.com to user’s browser.
3 Likes
By the way JFrog (the company behind bintray) – does have a single sign-on API! They also have oauth support as well I believe – though I’m not sure – I didn’t look too closely – I asked quickly…not sure if we have to host it ourselves or if they host it…
Emailed Bintray support regarding CORS:
Email Response 1:
Email Response 2:
I have contacted Bintray support, and they said that bintray.com does not support cross origin requests. They have created a ticket for it and hopefully CORS support will be added by this month end.
Does anyone know about using a non-browser based HTTP client to invoke requests from code ? (or) How should I proceed further until the CORS support is added to Bintray?
It’s exactly what I suggested in the reply above:
I think you should be sending queries to api.bintray.com from your server and not from a script in a browser.
Restating you should expose a rest service on your server, which will use any http client of your choice and delegate requests to api.bintray.com. Your webpage will call your rest service instead of api.bintray.com.
3 Likes