You should not delay. I won’t have much time to think about this in the next month; I’m trying to share a blast of thoughts right now that hopefully can guide some of the choices you all make. Let me try to summarize some key points.
We have two goals here: reusable widgets, and user-configurable dashboard(s).
Reusable widgets
- Our current technology stack (uiframework+gsp + angular 1.x) has an expiration date; we know we’ll need to move to something new, but we haven’t yet decided what. And we’re not gong to decide right now.
- The future technology stack will surely involve modern HTML, CSS, JS, REST, and a component approach.
- The configuration interface for each new widget should be “plain old json” defined by the domain of “a widget you can embed in a dashboard” and not be specific to uiframework.
- Someday we’ll rewrite the JS behind the widget (so don’t worry about this), but hopefully we can preserve the HTML+CSS and any new REST calls (so, get these right)
User-configurable dashboard(s):
App Framework, and its Apps with Extensions is a very helpful generic tool, but Bahmni has a much better specific solution to configurable dashboards.
(Actually I think it’s a better philosophical approach for OpenMRS, since it’s more approachable by implementers. I mention this a bit in this post: Managing App Definitions and Extensions in OpenMRS - #9 by darius)
Basically, instead of the model where you add a bunch of extensions that attach to the “patientDashboard.firstColumnFragments” extension point, the model is to write a dashboard config file. Here is their default version of dashboard.json.
The benefit is that it’s clear how a typical admin configures their dashboard (just edit the file, to change labels, or add widgets) and how to handle multiple dashboards (just have two files).
You’d need to write glue code that takes this json and uses uiframework to actually render the dashboard and include the widgets, but eventually we’d be able to just rewrite the glue code for a different tech stack, but the dashboard configs could remain exactly the same.
I would envision something like:
{ sections: [
{
title: "String or MESSAGE_KEY",
icon: "stethescope",
widget: "coreapps.latestObsForConceptList",
widgetConfig: {
concepts: [ "CIEL:5089", "CIEL:5090" ],
maxAge: "1y"
}
}
// and more widgets here...
]}
The glue code would take care of applying decoration, and knowing that “coreapps.latestObsForConceptList” means ui.includeFragment("coreapps", "latestObsForConceptList").
]
