> Yeah, sounds like many scripting languages... except shell ;-) > Agreed, there is always some distribution specific glue needed. I'm > leaning toward a 'meta configuration' (in XML) which can be edited, > verified, and translated into distro specific configurations. Ah I see you added another abstraction layer in form of XML and have a kind of meta-format. Sounds interesting.
We use a more UCI-based approach using an abstraction layer called CBI. The interface-designer just specifies a kind of model in Lua describing the scheme of the UCI file. This models conatins relations between configuration section and values like: there is a section, containing an on/off switch "enabled" and an optional text-value "dummy". There is another text-value "dummy2" but it will only be used when "dummy" is set. See this example: http://luci.freifunk-halle.net/WebUI/Documentation/ModulesHowTo#CBImodels The CBI then uses an appropriate renderer (at the moment HTML-templates) to create the output and validate the user input. > As such, it is too bad it (the advanced logic part) can't be > used outside of the GUI framework... or can it? You could for example use some Lua-ncurses bindings and write a CLI renderer for the CBI then you could completely reuse your models and i18n-files for a different thing and create a console based adminsitration app out of it but as long as you don't write an UCI -> non-openwrt-configuration scheme translator it stays OpenWRT specific. And of course you cannot use any non-CBI-models like your HTML-templates that you may have written for something like a statuspage that shows your memory consumption. But regarding this you will use a different approach for such a thing when you use ncurses. But at least you could reuse the LuCI system library function that fetches the memory consumption information into a usable data structure. > I'm not suggesting one approach is better than others. Developers tend > to work with that they know (or otherwise have an interest in). And, one > thing is for sure, with a user interface, no one solution is for > everybody -- particularly so in OpenWrt devices, I'd say. That's right. Your approach also has its advantages and that's good. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
