注：
下文“几个元素”中，属于“总结”。
是在编写本文是为了理清思路，边整理思路边写下的。
几个元素：
在 OpenWrt 使用 Luci – Web。
Luci 使用 lua 语言作为后台。
Luci 使用 lua 通过 uci 库读取和修改 OpenWrt 协定的 UCI 配置文件。
OpenWrt 内协定 UCI 配置文件，并提供了不同的接口操作它，其中之一是实现了 lua 语言的 uci 库。
Luci 框架内基于 lua + uci 库编写了 CBI 框架 – CBI 框架是 Luci 的子框架。
CBI 框架加载入 uci 配置文件相应的 lua 模块，对于 HTTP GET 能够以 CBI 框架的运行逻辑将 UCI 配置文件转化渲染成用于 Web 前端显示的 HTML 做 HTTP Response；同样对 HTTP POST 也以 CBI 框架运行的逻辑将 form 表单修改写入到 UCI 配置文件中（和生效）。
由于 UCI 有着规范的格式，以及 CBI 框架的 OOP 实现，我们不需要从头如 读取 UCI 配置文件，写出如何渲染成 HTML 的代码再 Response 到 Client（浏览器）；这些操作是可以抽象出来的一套可重用的参数和运行逻辑（方法），用户（promgramer）只需要编写针对细分的不同的配置文件内容的 CBI 模块代码即可（即，OOP 中的 class 已经被实现好了，只需要根据不同的实体内容实例和调整实例内容即可）。
因为 CBI 框架的高度可重用性（配置文件大同小异，用户（user）管理网页风格统一），所以我们可以设想只要在编写的 CBI 模块代码中指明该模块关联的 UCI 配置文件，那么 CBI 框架就能够将该 UCI 配置文件以写好的有限的规则读取出来并显示在浏览器上 – 但是因为我们需要控制配置文件中的哪些部分需要显示，哪些部分不需要显示；哪些部分以何种方式显示，另一些部分又以另外的什么方式显示；所以我们除了声明配置文件外，还需要声明这些内容 – 这很类似“声明式”编程，后面具体会感觉到。
（另外一提，这点和 Web 开发的后台管理网站没有本质区别，后台管理网站也是通过编写大量通用的代码涵盖大范围的内容类型（数据库，数据 type）以做到对大部分编写的数据模型无需额外编写管理页面，直接能够以通用的模板显示出来并且能够操作）
Luci 框架亦是 MVC 模式，其中 CBI 即是 model，因为用户（user）管理网页（路由器的 Web GUI）没有很多花样，所以基本上需要的前端模板 luci 都提供了 – 即用户编写了 CBI 模块即可，CBI 框架渲染时的运行逻辑能够使用既有的模板为浏览器提供 HTML 显示。当然，在一些需要以特殊方式显示或者提供更丰富的功能的地方，我们仍然可以自己编写模板（view），然后在 CBI 内指定哪些 UCI 内容使用该模板显示。
Luci 框架的控制器是理解 Luci 框架运行逻辑的关键，它主要将用户编写的控制器规则生成 URI（路由）（并且提供了反向解析的接口），用户（user）只需要在浏览器访问 URL，Luci 就能够通过控制器执行程序中定义的处理代码（比如 CBI 模块）得到处理代码（方法）的返回内容作为 HTTP 响应（View），即 controller -> model -> view（view 中又包含 controller URL）。
详解 Luci 框架 – 将分以下步骤进行（可以仔细看一下，有助于理清思路）：