Community, I need your advice with how we should handle the OCL Module.
Situation: We want to be able to remove the OWA Module from our 3.x RefApp distro, and currently it’s just the OCL Module preventing this. The OCL Module is the last remaining OMOD that depends on the (effectively deprecated) OWA Module.
Ideas:
Turn the OCL Module into a 3.x App.
@ibacher has already set the groundwork by setting up an ESM monorepo and skeleton of the work on GitHub .
Concern A: This means the OCL Module requires folks with JS skills to maintain it, right?
Concern B: And I guess the recent Java-based work on the Diff-Check-Review feature would have to be re-done, right?
Convert to a JSP OMOD.
This would mean that the OCL Module remains a Java-based module. Maybe this is fine, because we want OCL tooling to be a value-add to all implementers, regardless of whether they are using JS frameworks or not.
What do folks think we should do?
I was going to encourage a GSOC project for option 1, but if we don’t actually recommend that option, I should take that project down.
I would suggest we keep the OWA that already exists around for the 2.x UI and move to a microfrontend for the 3.x UI.
To be very clear about this: the OCL module is and will remain a Java-based module. The current frontend for the OCL module is already a Javascript-based application (that’s in essence what an OWA is). The idea is just that we replace one JS-based application with a different JS-based application that fits into our newer UI.
Yes, but:
The current OWA is also a JS-based application, so this is no different from the existing case.
We need JS programmers who are familiar with the OCL stuff, at least to continue managing the Dictionary Manager anyways.
The “meat” of the functionality of the module is still provided by the same Java code.
Not really. The existing OWA is a JS application that interacts with the backend via the REST API, i.e., in exactly the same way as the 3.x frontend. Any Java-based work done from the diff-check feature should be reusable. The UI that displays the diff-check (if any) would need to be redone.
Thanks @ibacher and @dkayiwa for the clear explanation. Am actually interested in this project and am going to create a post specifically for the project so that I can get a clear insight or if its okay we can maintain the same thread.
+1000 to refactoring the OCL subscription module’s frontend (along with any other modules we need to refactor) to adopt OpenMRS 3 approach to frontend.
Thank you all for your feedback & explanations here! A follow up question based on these parts:
It does make me nervous imagining that we’d have two different UIs to maintain - one for 2.x users, one for 3.x users - because we struggle enough to keep the current OWA-based UI maintained.
So, sorry if this is a silly question, but: Would RefApp 2.x users not be able to use the 3.x-UI-based OCL Module on it’s own? e.g. would they also need to download the spa module? (And if so, maybe that’s not all bad?)
i.e. - Can we not just have 1 UI to maintain for this module?
Well, assuming they had the SPA module and the framework, they could use the 3.x UI. The idea isn’t to maintain two UIs indefinitely, just to continue to provide the existing UI and add any new features to the 3.x line.
We can if we use the JSP option, but that seems to be going backwards, i.e., we’d have to rebuild the UI to work as a JSP right now and it would end-up looking more similar to the existing parts of the Admin UI than what it does today (because that UI depends heavily on the OWA module and the libraries added by the 2.x UI).