Luci coding: making sure 'higher level' menus exists from a leaf page

@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:

  1. 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.

  2. 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.

  3. I personally prefer granuality to monolithic.

you can use something like

if not lookup("admin/network") then
  entry("admin/network", firstchild(), _("Network"))

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.