How to write a router interface 1-luci development Primer

HOWTO: How to write Module-----------------This part is mainly translated document on GitHub

Note: You should read the module reference if you intend to add modules to Luci integration.

This tutorial shows you how to write your own Luci WebUI module. In this tutorial, we assume that your LUCI installation directory Lucidir (if you are currently using the installation version/usr/lib/lua/luci), and assume that your LUCI installation accesses your Web server via/cgi-bin/luci.
Method route (for the scheduling process)

To write a module, you need to understand the basics of the Luci scheduling process. Luci, a scheduling tree is established by performing the indexing function for each controller that is available for use. In the CGI environment variable PATH_INFO will be used as in this dispatch tree, for example:/cgi-bin/luci/foo/bar/baz will be parsed to Foo.bar.baz

To register the functionality in the dispatch tree, you can use the Luci.dispatcher entry function (Entry functions). The entry requires 4 parameters (2 of which are optional):

Entry (path, target, Title=nil, Order=nil)

• Path is a table structure that describes the location of the dispatch tree : for example, {"foo", "Bar", "baz"}, path will be inserted into Foo.bar.baz.
• Target describes the action that will be taken when the user requests the node. There are three predefined objects that are most important (call, template, CBI), which they will describe behind this page
• Title defines the options in the Visible menu, which is the title content that can be seen in the final Luci interface (optional)
• Order is based on this number so that the nodes on the same level are sorted on the menu (optional)

You can assign more parameters to the entry function by manipulating the return value of the node table . Some examples of typical parameters are:

• I18N defines an interpreter (file) that automatically loads when a page is requested
• dependent prevents plug-ins from being true in their parent node, that is, adding plug-in dependencies
• The leaf stops parsing the node's request, and there is no further scheduling tree
• Sysauth requires users to authenticate with user accounts for a given system

Below is the naming and use process

Now that you know the basics of scheduling, we can start writing the module . But before we do, we must first select the directory and name the new node that belongs to you.

Let's say you want to create a new application called MyApp , and the myapp module is mymodule .

So you must create a subfolder Lucidir/controller/myapp, under which you create a mymodule.lua file with the following contents:

1 Module ("luci.controller.myapp.mymodule"package.seeall23  function  index ()45End

The first line requires Lua to correctly identify the module and establish its scope. The index function will be used to register the action in the dispatch tree.

So far, you've got a new node, but there's no functionality in that node.

Let's say you want to reuse your myapp.mymodule module, then you have to start the last step.

Actions

Reopen Lucidir/controller/myapp/mymodule.lua and add a function similar to the following:

1 Module("Luci.controller.myapp.mymodule",Package.seeall)2 3 functionindex ()4Entry ({"Click"," Here"," Now"}, Call ("Action_tryme"),"Click here",Ten). dependent=false5 6 End 7 8 functionAction_tryme ()9Luci.http.prepare_content ("Text/plain")   TenLuci.http.write ("Haha, rebooting now ...")    One luci.sys.reboot () A End

Now enter /cgi-bin/luci/click/here/nowin the browser (Http://192.168.1.1/luci/click/here/now should be on your openwrt system)

You can see that these actions have been added to the schedule tree.

As you may or may not be aware of: The CGI specification requires you to send Content-type first before sending your content header. You will find several shortcuts (as used above), as well as the Luci.http redirection function in the module

Views

If you just want to show the user a line of characters or some interesting family picture, then using Html-template is enough. The template can also contain LUA code, but you must understand that just using a template can write dirty code.

Now let's create a small lucidir/view/myapp-mymodule/helloworld.htm with the following:

1 <%+Header%>2 <H1><%: Hello World%></H1> 3 <%+Footer%>

Then add a line below Index-function to your module file.

Entry ({"My", "new", "template"}, Template ("Myapp-mymodule/helloworld"), "Hello World"). Dependent=false

Now enter/cgi-bin/luci/my/new/template in your browser (http://192.168.1.1/luci/my/new/template on your openwrt system).

You may have noticed these strange tags, which are tokens used by Luci 's template handlers . Using headers and footerin a standard designis a good choice .

CBI Models

The CBI is the coolest feature in Luci. It creates a standard user interface and stores the content in a specific UCI config file. you just need to describe the structure of the configuration file, and the CBI program will help you with the rest. This includes generating, parsing, and validating HTML forms and reading and writing UCI files.

So we have to be serious. Create an instance Lucidir/model/cbi/myapp-mymodule/netifaces.lua its contents as follows:

1m = Map ("Network","Network")--We want to edit the UCI config file/etc/config/network2s = m:section (Typedsection,"Interface","Interfaces")--especially the "interface"-sections3S.addremove =true --Allow the user to create and remove the interfaces4 functionS:filter (value)5      returnValue ~="Loopback"  andValue--Don ' t touch loopback6 EndS:depends ("Proto","Static")--Only show thosewith "Static"7S:depends ("Proto","DHCP")--or "DHCP" as protocol and leave PPPoE and PPTP alone8 9p = s:option (ListValue,"Proto","Protocol")--creates an element list (select box)TenP:value ("Static","Static")--Key and value pairs OneP:value ("DHCP","DHCP") AP.default ="Static"  -  -S:option (Value,"ifname","Interface","The physical interface to be used")--This would give a simple textbox the  -S:option (Value,"ipaddr", Translate ("IP Address"))--Ja, das ist eine i18n-funktion;-) -  -S:option (Value,"netmask","Netmask"):d Epends ("Proto","Static")--remember this ' depends ' function from above +  -MTU = S:option (Value,"MTU","MTU") +Mtu.optional =true --This one is very optional ADNS = S:option (Value,"DNS","Dns-server") atDns:depends ("Proto","Static") -Dns.optional =true - functionDns:validate (value)--Now , that ' s nifty, eh? -     returnValue:match ("[0-9]+\. [0-9]+\. [0-9]+\. [0-9]+")--Returns Nil If it doesn ' t match otherwise Returns match - End  -  inGW = S:option (Value,"Gateway","Gateway") -Gw:depends ("Proto","Static") toGw.rmempty =true --Remove Entry if it is empty +  - returnM--Returns the map

Of course, don't forget to add your own index-function function.

1 entry ({"admin""network""  Interfaces"}, CBI ("myapp-mymodule/netifaces""  Network interfaces"). dependent=false

How to write a router interface 1-luci development Primer