Open ndegwamartin opened 3 months ago
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
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 https://github.com/onaio/fhir-tooling/pull/211
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.Implementation
efsity.yaml
~/.efsity/efsity.yaml
and the local/<current dir with efisty.jar>/efsity.yaml
file, the local one takes precedence.Acceptance Criteria
efsity.yaml
. We could expand to include the extension.yml
. If conflict.yaml
takes precedence.~/.efsity/efsity.yaml