So you want to reuse your components or code across more than one site. But that means storing configuration information unique to each site so your code will behave the way it needs to.What tools do you have to do that?
In IguanaX, you can use :
| Expand | ||
|---|---|---|
| ||
Custom Fields are a good method for configuring details which apply for to a specific component. You can create custom fields in the Translator config.json file and include default values that are stored in source control. Custom fields entered in the Component Card are encrypted and stored locally in the working directory . See Custom Fields Component Configuration Files. |
| Expand | ||
|---|---|---|
| ||
These Environment are good for dealing with properties which need to be defined across the server. Environment variables They are stored locally in the working directory in IguanaEnv.txt. your working directory Environment Variables Configuration File. |
| Expand | ||
|---|---|---|
| ||
External configuration files can be used to store encrypted configuration values that can be accessed and managed across many components. To securely store and load configurations in the Translator you can use the Encrypt Library. |
| Expand | ||
|---|---|---|
| ||
I wrote There is a small library to allow one to load a JSON file from another component when you supply the name of the component and the name of the file. This might be helpful: CONFIG Library |
When using configurations in the Translator, there are two general rules:
| Expand | ||
|---|---|---|
| ||
It’s a good idea to reduce the number of configuration parameters if you can. Less is more. If you find you never change a setting, consider removing that setting from your list of configuration parameters. Try and simplify things. See What are bottlenecks and why do they matter? For instance say you need to configure retry settings for your HL7 listeners - why not come up with some universal settings that ‘just work’ at 100% of your sites without needing any special configuration - does not seem like a better idea than engaging in busy work? |
...
| |
It is best to avoid hardcoding values! Instead, parameterize any values that can change. In the Translator, you want to see as little text as possible. Good values to parameterize are values like URLs, file paths, database names, etc.  |
| Expand | ||
|---|---|---|
| ||
What you want to avoid is having configurations scattered all over your code - this makes it difficult to support and see what is configurable. We recommend that you capture your configurations in the main.lua module only, and then pass your configurations to your functions. This has a side effect of making your functions more portable - if you need to call a function anywhere. For example with configurations stored in custom fields, you can just pass the table of  |