# openmrs.js (JavaScript API Wrapper)

**URL:** <https://talk.openmrs.org/t/openmrs-js-javascript-api-wrapper/5355>\
**Category:** Development\
**Tags:** javascript\
**Created:** [March 16, 2016, 8:39pm UTC](https://talk.openmrs.org/t/openmrs-js-javascript-api-wrapper/5355 "2016-03-16T20:39:03Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [March 18, 2016, 6:21pm UTC](https://talk.openmrs.org/t/openmrs-js-javascript-api-wrapper/5355/16 "2016-03-18T18:21:23Z")

</div>

> [@raff](#):
>
> a way to translate OWA pages

I’m curious about how to approach this. I know how to solve it in Angular, and other frameworks have similar mechanisms.

But if we want a static framework-independent solution to this, we need something like a preprocessor that is run on html files as we serve them up. (Note that we would not actually want to use the current cookie locale resolver in that case, since it would make the static resources uncacheable.) This, however, is totally antithetical to how OWAs are supposed to work.

I was thinking about this in the context of how letting a distro or sysadmin configure some global CSS to be applied to every page (even OWA ones) in this comment (my code snippet was eaten my markdown, so I just fixed that now):

> [@Open Web Apps, common application functionality, and coexistence with refapp apps](https://talk.openmrs.org/t/open-web-apps-common-application-functionality-and-coexistence-with-refapp-apps/5179/8):
>
> Definitely curious to hear what @sunbiz thinks. I think our philosophy should be that these are OpenMRS Open Web Apps, not generic OWAs that could run on OpenMRS, DHIS2, or any arbitrary container. We’re trying to build an application out of coherent apps that form an EMR, not a collection of arbitrary apps. And we should have some proprietary OpenMRS extensions that we recommend people follow. Examples: Add extensions like “openmrs-require-core-version” and “openmrs-require-modules” that th…

At this point I think the right approach is to just promote best-practice usage of a particular AngularJS approach (by default I’d choose the one Bahmni chose) + the same for other frameworks. (Including for my global CSS example, where that CSS can be loaded dynamically via JS.) But I’m curious whether anyone else thinks that macro preprocessing of the HTML files we serve is even worth considering.

---

_[View the full topic](https://talk.openmrs.org/t/openmrs-js-javascript-api-wrapper/5355)._
