This is a proof of concept and a WIP, not an actual PR.
It implements a method for automatic generating LUCI pages for a UCI
config file.
I'd like to hear your views before developing any further. Sorry for the lengthy post.
The basic idea is to have LUCI interface for packages with near zero effort. Only 2 .json config file and no need for web programming or internal knowledge of the functions/directives of luci-ng; and no need for an additional luci-pkg-name (perhaps only for translations).
It is mainly intended for packages, the core config should have custom pages (although for the example I used the system config).
Steps:
create a .json file with the description of the structure of the itself. This is in way similar to the definitions embedded in the many init.d scripts in calls to uci_validate_section section option:type:default
I used json as it was easier to integrate in http and more flexible to add properties. But this meta config file could be in any other format. In docs/autoUCI.json there is a description of a possible format.
add another .json with the mapping to the menu.d to make it appear in LUCI
all ready to use it in luci-ng
Thinking a little ahead, this description of the config file could be also used in init.d scripts, so that we don't have duplicate definitions of the same info, and we also ensure that changes in the config file go quicker to LUCI. (for instance in the system config the options to get NTP servers from DHCP were added, but never made it to LUCI interface).
With the proper hooks, this files could also populate the documentation/wiki tables describing the UCI params of each file.
For this proof of concept, the page is still hardcoded with a specific config file (it should be parameterized with the ngRouter), and monolithic, meaning that it edits the whole file at once or nothing.
But the idea could be extended into the CBI directives, with some kind of "autoUCI" param so that it automatically generates the proper level: the whole config (like the example) if at cbiMap, or a specific section if at cbiSection (so that one con mix manual with automatic UI), or even at cbiOption level.
Signed-off-by: Adrian Panella ianchi74@outlook.com
This is a proof of concept and a WIP, not an actual PR. It implements a method for automatic generating LUCI pages for a UCI config file. I'd like to hear your views before developing any further. Sorry for the lengthy post.
The basic idea is to have LUCI interface for packages with near zero effort. Only 2 .json config file and no need for web programming or internal knowledge of the functions/directives of luci-ng; and no need for an additional luci-pkg-name (perhaps only for translations). It is mainly intended for packages, the core config should have custom pages (although for the example I used the system config).
Steps:
uci_validate_section section option:type:default
I used json as it was easier to integrate in http and more flexible to add properties. But this meta config file could be in any other format. In docs/autoUCI.json there is a description of a possible format.Thinking a little ahead, this description of the config file could be also used in init.d scripts, so that we don't have duplicate definitions of the same info, and we also ensure that changes in the config file go quicker to LUCI. (for instance in the system config the options to get NTP servers from DHCP were added, but never made it to LUCI interface). With the proper hooks, this files could also populate the documentation/wiki tables describing the UCI params of each file.
For this proof of concept, the page is still hardcoded with a specific config file (it should be parameterized with the ngRouter), and monolithic, meaning that it edits the whole file at once or nothing. But the idea could be extended into the CBI directives, with some kind of "autoUCI" param so that it automatically generates the proper level: the whole config (like the example) if at cbiMap, or a specific section if at cbiSection (so that one con mix manual with automatic UI), or even at cbiOption level.
Signed-off-by: Adrian Panella ianchi74@outlook.com