Efsity | Add support for dynamic configuration via a global file

[ndegwamartin]

As FHIR Core evolves there's a need to make the platform extensible. One such opportunity is with FCT tooling.

FHIR core processed data in the JSON format for both configs and content. JSON is flexible in that fields can added or redacted frequently (more than code changes). Thus it makes sense to decouple any configurable references to JSON fields from the code.

One way we can implement this is to introduce some type of (global) property file for efsity, e.g. .yaml format which can have various sections with the configurable entries. e.g.

efsity.yaml

---
questionnaireTranslatables:
     - text
     - display

configTranslatables:
      - saveButtonText
      - title
      - display
      - actionButtonText
      - message
      - primaryText
      - secondaryText

Implementation

• We can have standard locations where the config file is expected to be on the user machine as well as a flag whose value points to the location(absolute) of the configuration file.
• We can name the default file efsity.yaml
• We can use the names of the collection variables in code as the keys in the yaml. The names should be in full and clear in terms of what they represent.
• We should have some feedback for the user in the logs any time a file is found or given and print it out
• The FCT class FCTConstants.java can still have the existing configs as defaults. Once the support is added documentation should be added to the class that the configs can be extended via the configs file.
• The configurations in the file will be added on to the default ones on FCT . i.e. the resulting configuration should be a union of the set
• Incase there are any conflicting configurations, the configuration file will take precedence.
• In case the user has defined both the ~/.efsity/efsity.yaml and the local /<current dir with efisty.jar>/efsity.yaml file, the local one takes precedence.

Acceptance Criteria

• We can name the default file efsity.yaml . We could expand to include the extension .yml. If conflict .yaml takes precedence.
• Efsity should search for and import configurations of a file at the root (current) director the efsity jar is being run
• Efsity should search for and import configurations of a file at the path USER_HOME path e.g. ~/.efsity/efsity.yaml
• The local efsity config file should take precedence over the global efsity config file
• The configs in code e.g. those in FCTConstants.java and the ones in the loaded config file should perform a set union operation.
• Relevant documentation on the efsity README.md

[pld]

To clarify, is this a file that configures how efsity operates?

Is this file global or per project, like would you put it into the project resources folder?

Can we write the docs for this first? Basically expanding on what you have here with examples, then we can use that to guide the implementation, we'll need the docs anyhow to give them value, and drafting them will let others comment on the use cases earlier before we commit to the implementation

[ndegwamartin]

To clarify, is this a file that configures how efsity operates?

Is this file global or per project, like would you put it into the project resources folder?

Can we write the docs for this first? Basically expanding on what you have here with examples, then we can use that to guide the implementation, we'll need the docs anyhow to give them value, and drafting them will let others comment on the use cases earlier before we commit to the implementation

Yeah this is such a file, meant to be used at runtime. It is for configurations meant for efsity the tool rather than project specific. For context this stems from the PR here #211