How to make the reference application more configurable

Development
21

@gutkowski Distribution dependent OWA which gets its look & styling of the platform it is running on

22

@ssmusoke I was hoping there’s some other way :slight_smile: I will try to prototype some solution and report it on Talk, when I will come up with something concrete.

23

hi @gutkowski were you able to make progress on this?

24

@dkayiwa @wyclif @darius I would like to bring the discussion from this thread Redirecting Link to Create/Find Patient plus View Patient from Legacy UI to Ref App UI here

If I am to add a Register Button to the search page, how do I ensure that it redirects to the correct registration app in my installation?

  • Does App Framework have a registry that can be tapped?
  • I am assuming that there could probably be more than one registration app depending on the location being used (future feature)

Thanks in advance

25

The redirect URL when the button is clicked just needs to point to the register patient page with the appId parameter value set to your registration appId, an example URL is openmrs/registrationapp/registerPatient.page?appId=referenceapplic2ation.registrationapp.registerPatient which is the default URL in the ref app when you click the Register Patient app, all you need to change is the appId

26

@wyclif How will the appId change for an implementation that changes the registration app (which is most of them)

27

When you asked, > how do I ensure that it redirects to the correct registration app in my installation? I assumed you already knew how to customize patient registration and that you had it in place. This page describes how to configure/customize the registration page, under the ‘Initial steps’ subsection on that page, bullet 8 mentions how to set the URL to your customized page, that’s the same URL with the appId that you would redirect to when the button is clicked.

28

@wyclif Let us step back a bit so that you understand what I am trying to do:

  1. On the Search Widget page I would like to add a Register Patient link. For Reference Application this would point to ~/openmrs/registrationapp/registerPatient.page?appId=referenceapplication.registrationapp.registerPatient

  2. However many implementations override this page with their own custom pages such as ~/openmrs/registrationapp/registerPatient.page?appId=implementation.registerPatient

So my question is: How do I ensure that the Register Link on the search widget can be “easily” configured to point to the correct patient registration url for the implementation

29

@ssmusoke, so, you want to add a new feature, like “Add a link to the registration app, from within the find patient app” and this requires the system to have a general understanding of “what is the ‘main’ registration app”.

The appframework module does not natively support the idea of “the ‘main’ implementation of something” and the Reference Application doesn’t either. So you’d need to introduce this.

Going back to the first post in this thread, one approach is to replicate what PIH did in introducing a global property for “default patient dashboard”. I don’t like this as a long-term solution if we have to repeat it a lot, but since there’s a precedent for it, and we’ve only been adding one per year, maybe that’s the way to go. It would be straightforward to also introduce a “default registration app” global property and there’s no new design required to implement it like this.

I think the “better” long-term alternative is to explicitly have a way for modules (or system configurations) to register their capabilities (e.g. “registrationapp/registerPatient.page?appId=referenceapplication.registrationapp.registerPatient has the ‘Register Patient’ capability”) and for the implementation to indicate which is its preferred url for each capability. This may be overkill. This could be implemented within the appframework module by using:

  • Extension Points for “Register Patient capability”
  • Extension to say this URL has “Register Patient capability”
  • A new appframework feature to record which is the preferred URL for each capability.

Earlier in this thread, @gutkowski did a bunch of work on enabling “page overrides”. I only just now peeked at this code, and at first glance I’m concerned that this implementation is specifically in the uiframework module, and wouldn’t solve the problem when we’re mixing uiframework-backed and OWA-backed pages. So (I think) this would need to be rewritten if it’s to be the way going forwards. (It may be independently useful on its own for some other use cases.)

So, @ssmusoke, doing the GP thing one more time is sufficient for this use case; there could also be a more design-intensive approach if you want to go that way.

30

@darius Thank you for the detailed explaination, and I think the way to go is have a GP (defaulting to blank) for now, then looking into a more detailed capability registration mechanism. I will add an EPIC for that in Reference application - targeting 2.7