@jow @hnyman In my work on separating out luci-mod-admin-full into separate apps I ran across an interesting problem: How do I make sure that for a particular leaf app that the e.g. /network/admin exists if I want to avoid depending on luci-mod-admin-full? Should I perhaps move the top-level menu 'shell' into a separate package that is depended on by everything else? (e.g. luci-mod-base-menu-xxxx)?
I am not sure if your goal of separating some core router functionality to separate apps is wise. That would easily generate a dependency spaghetti.
What is the reasoning for splitting admin-full? What is the benefit?
There are two goals:
-
To make it easier to pick and choose what ot use when doing a combination of luci and luci-ng (or third party luci replacements beings worked on), so that having a functional gui doesn't depend on building 'all' of core modules before it's a viable gui.
-
For things like @EricLuehrsen replacing dnsmasq, or if someone wants to use unbound + a (yet to be done) isc-dhcp-server app that it's not blocked by core stuff.
-
I personally prefer granuality to monolithic.
you can use something like
if not lookup("admin/network") then
entry("admin/network", firstchild(), _("Network"))
end
entry("admin/network/foo", cbi("whatever"), _("Child page"))
1 Like
Moved discussion here:
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.