Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sometimes, a usermodule would benefit a lot from being able to programmatically generate the options of a select field in the module's config – both when editing the configuration of and instance, and when creating a new instance. In some cases, it's possible to do this through the postRender functionality, which allows the developer to pass javascript for the alpaca form that is run client side when the form has rendered on the user's screen. It can also be possible in some cases to use the "click" and "onFieldChange" attributes to pass a function as text in module.json, which is executed on the element's click and onFieldChange events respectively.
But this is sometimes not a good solution, as the client side script is bound to the client scope (no access to z-way internals not provided by the API), suffers potential lack of access to the z-way local network, and is functionally limited. It also suffers from the pains of cross browser support. Although it's usually possible to create workarounds, these will often have to be awkward for both the developer and the user – for the developer because of the need for a lot of extra code, and for the user because of the frequent need to instantiate the module first, and then go back into the new instance's settings to do changes.
The change of AutomationController.js in this pull request implements the exact same approach that is found in zwave-smarthome -> app/services/services.js -> replaceModuleFormData() for translating text to functions for client side evaluation, except that it replaces the text with the (server side) evaluation of this function.
The reason why it should be evaluated on request, and not on module load, is that whatever the function generates could depend on some state that changes over time. This way, it is evaluated both on showing the config when instantiating new module instances and when editing the config of existing ones.
In use, the options section of module.json, in its simplest form, could look like this:
This example is nonsensical in its simplicity, of course. A more realistic example, which is also a use case of mine, is to generate a list of physical devices. Which could look like this: