[RFC] gluon-web-model: Make model-maps extensible #1662
Conversation
It was not possible to modularize single sections of forms in the config mode. This commit adds support for ´Supramaps´. Using supramaps it is possible to create an additional directory where inframaps reside. E.g. a Lua model file with a same-named directory (excluding the file extension) defines a Form element and returns it. This is a supramap. If Lua files exist in that directoryn the Form element is available in their environment as "Supramap". Thus these files can add additional sections which are "inframaps" and must return the modified supramap. This allows e.g. modularizing the password field in the gluon-web-admin package as an own package without hampering usability.
|
Can you give an example how LuaSrcDiet affects what you're trying? It should not minimize non-local names. |
|
@NeoRaider Ah thank you. I haven't tested it, yet. I was just unsure about how it does the diet. I'm unsure about the naming, too as this can only be used with forms. Maybe I should add a check whether the returned "map" is an instance of a Form. Actually it's not really a map. At the moment all these points are not really important as I just need a working feature to separate the sections in different files to allow separation of packages. Improvements can be done afterwards, but it's your decision if and in which form it gets merged... |
|
I don't think any of this is necessary. Components can just be provided by regular Lua modules, without any need to glob for files to load. |
|
@NeoRaider The goal of this is to modularize the packages to allow to specify the packages that one wants in the site.mk file. Gluon is not modular enough at the moment to use it for different purposes than Freifunk. E.g. there should be a gluon-web-wifi-core package, a gluon-web-wifi-private-wlan, a gluon-web-wifi-outdoor-mode, a gluon-web-wifi-client, a gluon-web-wifi-mesh etc. package. Not one "provides all" package. The same for gluon-web-vpn-core. There should be a gluon-web-vpn-fastd-n2s, gluon-web-vpn-fastd-n2n, gluon-web-fastd-s2n etc. package. They should provide additional files that are e.g. being embedded as a section in the form of gluon-web-*-core. Is it clear what I want to achieve here? It's only possible with globbing. Dead code is bad code in embedded development. Thus it is no option to enable/disable functions in the site.conf. |
|
Such globbing would only be useful in very specific parts of the web UI. I don't think such a facility should be a default feature of gluon-web, but something that is explicitly used by a model script. Also, we don't really support multiple VPNs or multiple mesh protocols at the same time, so rather than globbing, such modular models could just load a module with a special name, rather than globbing for multiple files (see the the optional OSM feature in (Picking up the discussion from #1329, I'm not sure if now it a good time for other projects to consider using Gluon as a base for their platform - I still hope we can revamp our network configuration to become more flexible eventually (see also the network-rewrite milestone, but my current plan for that involves a complete replacement of netifd, fw3, most of UCI, and possibly other tools with something better suited for our requirements.) |
|
I understand your concerns, but I don't see any other way. At the moment we are using globbing already for the models. The concept can of course be improved. That's why I opened this as a RFC. What I'm thinking of is that we could have "core"-models/supramaps similar to the categories of OpenWrt's LUCI, but not with nested navigation, but a single form with multiple sections instead. That is cleaner, more modern UI design. At the moment we have e.g. the problem, that the state is getting lost when we switch to the Expert mode. There should be no different site for that. Instead the General setup/Wizard page should be a category with the same tabbed navigation like in the Expert mode. And the expert forms' categories should be toggled using a Expert mode checkbox. It's hard to explain with words only. I'm going to make a design concept so that I can show you, what I want to achieve. Another issue that would be solved with this approach is responsiveness. On my devices with a smaller display I have to scroll horizontally to see all links. It's getting too much. There should only be e.g. "General", which is the only visible category when the expert mode checkbox is disabled, "WLAN", "Ports", "VPN", "Plugins" and "System". Where "Plugins" should be used by community-maintained packages that are too specific to be upstreamed. Edit: With "at the moment we are using globbing already" I mean the dispatcher is using it. I'd rewrite the dispatcher if that is needed and simplify it as far as possible. Actually I'd like to get rid of the controller files altogether as they only save the name of the model and their order and use the model files' names instead and prepend a number like we do with the sysupgrade files. Edit2: The Plugin page should not be displayed without any independent plugins. Later we may introduce a real plugin system where people can e.g. install software for file servers or whatever at runtime. |
CodeFetch
changed the title
|
I decided to rework Gluon's web interface based on the new LuCI2 concept. A helping hand would be awesome. |
I haven't tested a build with these modifications, yet. Is there a whitelist for LuaSrcDiet or does it ignore variable names starting with capital letters? I'd like to have this feature to increase modularity of several gluon-web-packages including the mesh-vpn-fastd package. Then I can merge N2N support properly. Do you know a better way to achieve this?