Investigate technologies available for custom forms

[ifoche]

@tokland @matiasgarcia91 if you could please here document a bit what we talked last week about which limitations we have in the custom forms, that would be great. Nothing very extensive but just to record here the result of our conversation in this regard.

[tokland]

:book: Models

• dataSet.dataEntryForm
• program.dataEntryForm
• programStage.dataEntryForm

interface DataEntryForm {
    id: string;
    name: string;
    htmlCode: string;
    style: "NORMAL" | "COMFORTABLE" | "COMPACT" | "NONE";
}

dataEntryForm.htmlCode may include:

• HTML code
• In-line Javascript code (<script>...</script>)
• In-line CSS (<style>...</style>)

:construction_worker_man: Usage

Official documentation:

https://docs.dhis2.org/master/en/user/html/dhis2_user_manual_en_full.html#manage_customform

The most relevant info:

• Use the data entry events to run code (example: dhis2.de.event.formLoaded, dhis2.de.event.dataValuesLoaded,...)
• Data input values must have attributes id="<dataelementid>-<optioncomboid>-val"
• You have access to some global dhis2 utils functions (dhis2.de.api.xyz), check the documentation for more info.

Dynamics vs static forms

There are two main ways of using custom forms:

1. Javascript code that loads the required metadata on-the-fly and builds the HTML view from it.

   PROS:

   • You can build complex dynamic forms which depend on the current metadata in the server.
   • Simple global deployment. The form code could load some external JS code, which, in turn, would render the HTML. This way, a single deployed script could be directly used by many Dhis2 instances.

   CONS:

   • Does not work on off-line data entry.
   • Slow rendering.
   • Increases server load.

2. Static pre-generated HTML code.

   PROS:

   • Fast rendering.
   • It works on off-line data entry.

   CONS:

   • Whenever metadata relevant to the form (data set, data elements, categories, ...) change, the custom form must be re-generated.