O3: Support for HTML Form Entry in 3.x

Development
,
1

We want to update the community that Mekom & ICRC are working together to address the first piece of HTML Form Entry support in 3.x.

Let’s use this thread to confirm/discuss who is doing what.

Part 1: MVP workflow to open HFE form in 3.x

This is what ICRC/Mekom are currently working on. Special kudos to @icrc.psousa, the ICRC developer making this happen.

@mksrom @mksd @delphinep @icrc.psousa anything to add or correct here? Does this all match your understanding?

@ddesimone has voiced on Slack that PIH would like to make themselves available to help test, code review etc. (So, since we have 2+ orgs contributing to this, I’ve added this initiative to the community Product Roadmap).

image
image2090×928 146 KB

Part 2: iframe? (No one working on this…yet)

No one I know of is expecting native support for rendering HFE forms in OpenMRS 3. However, many folks are interested in having an HFE render within a frame within 3.0, even if it’s in it’s old style (and ugly).

I have not yet found an implementer that has prioritized this so I was (optimistically) going to try and get this done through a GSOC 2022 project, described here.

Background/Context of HFE in 3.x

  • The main need/user story is: “As an implementation who has many, many forms created with HTML Form Entry, we want to use 3.x while still being able to use our old HFE forms, so that we don’t have to go through a very expensive and painful process of changing all our HFE forms over to match the new 3.x form schema.”
  • While we want to switch gradually away from HFE in favor of an easier to use next generation form tool, HFE is still the major tool used by existing implementers, so 3.x not supporting HFE is a major adoption blocker. Basic support for HFE forms in 3.x would be a phenomenal value-add to all implementers using HFE and wanting to try out 3.x.

CC @mogoodrich @mseaton @ball @bistenes @aojwang @eudson @ssmusoke @mksrom

3 Likes
2

Sounds exactly right, thanks @grace !

1 Like
3

Just to comment a bit on this approach @grace, @aojwang , @bistenes , @mogoodrich and all - this seems reasonable, but HFE is reasonably well positioned to work directly (in an iframe or just within a div on the page) directly in MFE code I think. Certainly, we have existing code that renders view/edit/enter htmlforms and submits them to the backend entirely using Javascript / AJAX, using various jQuery scripts. Allocating a short amount of time into reviewing what is currently implemented here and how it might be adapted into the MFE landscape would likely be time very well spent, even if it just results in the conclusion that it isn’t compatible.

What can I do to help provide support into this?

Thanks, Mike

4 Likes
4

I support your point, @mseaton. In addition, rendering an HFE form in an iframe or div will provide a better user experience than opening a form on a new tab and closing/navigating back to SPA on form submission.

1 Like
5

Just to be clear, the workflow is not to open the HFE form in a new tab. It will open in the same tab the user is already working on.

3 Likes
6

Agree that we should review the view/edit/enter functionality that @mseaton describes above to see if we can use it within the MFE context.

2 Likes
7

@mksrom @icrc.psousa how is this work going? Can you provide a link to the relevant code?

Context: @kumuditha is interested in working on “Part 2” as described above; will be very helpful to reference how you have been approaching this so far.

1 Like
8

@grace @kumuditha Part 1 (O3-1041) is implemented - This is the PR with the changes

This change allows us to specify through configuration, on our distro, which HFE forms we want listed on O3 and opened by redirecting the user away from the SPA to the old style form.

The decision whether to open the form within O3 SPA or old style is made here

3 Likes
9

@icrc.psousa @grace Is there any tickets that I can work on, to get familiar :slightly_smiling_face:.