Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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.
In IguanaX, you can use :
are a good method for configuring details which apply 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 .
are good for dealing with properties which need to be defined across the server. They are stored locally in your working directory .
External configuration files can be used to store encrypted configuration values that can be accessed and managed across many components. We have two libraries that can be used to implement this: can be used to store and load key value pairs in a SQLite database of file. can be used to securely store and load configurations in the Translator.
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:
When using configurations in the Translator, there are two general rules:
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.
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 Configs into the function directly.