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 | ||
|---|---|---|
| ||
This is good Custom Fields are a good method for configuring details which apply for to a single specific component.See Custom Fields 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 Component Configuration Files. |
| Expand | ||
|---|---|---|
| ||
These are not too bad Environment Variables are good for dealing with properties which need to be defined across the server. See They are stored locally in your working directory Environment Variables Configuration File. |
| 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. This is all about eliminating bottlenecks (Eliminate bottlenecks with IguanaX). 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  |