@mksd Hey, how’s it going? Sorry to just be tacking on to this thread, but I was wondering if HTML form loading and visit action configuration is something you’re thinking about for Iniz. It’s something we’d like to refactor in PIH EMR, but maybe it would make sense to build it out in Iniz.
@bistenes yes it would be great, I’ve been thinking about it for while and I keep pushing this back. I haven’t really gotten my head fully around it but we can certainly kick start the design process.
As such having Iniz ensuring that the form is saved as it should once given the XML file is easy enough. Actually I have that code somewhere in an old module and it could be reused right away.
What bothers me more is that HFE forms are often not self-contained. Very specifically what could be tricky to handle properly is all the
<uiInclude/> statements for all sort of JS or CSS resources that often belong to the custom module that bundles the forms themselves.
I mean the ultimate goal here is to not have a custom module for bundling forms anymore right? It is easy enough to have Iniz to save the forms. Maybe that’s the scope you have in mind and by all means that’s already quite useful. But it’s quite more intricate to ensure that all their dependencies can also be part of a comprehensive config. Would the latter also be part of your scope?
@mksd, personally I don’t think that is a requirement in the near term. I think the assumptions should be that if htmlforms make references to particular features or metadata, that the distribution that these are being installed into has those features or metadata in place (or Iniz is able to mark them as dependencies in some way). All we are looking for is to version control and deploy htmlforms without packaging them into an OpenMRS module I believe.
A simple enough option would be for Iniz to become the resources provider by exposing those that it is given:
configuration └── resources ├── style.css └── utils.js
And this would allow you to do this: