管理员列表，前端到后端基本功能实现

首先，先做管理员列表，毫无疑问，得在User.php中添加一个管理员列表方法，因为是由控制器来负责渲染什么模板，如何渲染的。同时，也要有管理员列表对应的模板。将模板中对应的管理员列表模板，略作修改，就可以作为这次项目中的管理员列表模板了。

下面这幅图是User.php这个控制器中的管理员列表部分的代码。（前端代码的逻辑中，已经利用eq从session信息中判断你是否是超级管理员，是就给你看超级管理员界面，不是就给你看阉割过的超级管理员界面）

代码逻辑：（假如已经给管理员列表按钮添加了跳转到这个管理员列表页面的href）先给管理员列表页面该有的标题赋值->计算数据库中的记录条数，赋值给页面中的变量(不懂UserModel::count()方法，先猜这个，经过补充基础，发现就是这个意思)->判断是否是admin用户，根据判断给与不同的数据库记录赋值->渲染管理员列表模板

结合上面两张图，可以看到，控制器的每一个方法，对应的都是一个html模板。应该是为了规范和个人习惯吧，视频中，这里的title之类的赋值都在控制器中完成了。要是我的话，我可能会在html模板中进行修改，还是按视频中的方法来吧。感觉视频更专业一点。

在前端的模板中，用{eq name="$Think.session.user_info.name" value="admin"}来判断是否显示管理列表，只有超级管理员才会显示管理列表，普通用户管理自己的后台不需要看到其他的管理者信息。

下面用{volist name="list" id="vo"}来在显示页面的每一行显示相应的个人信息。这个name=list是在控制器的方法中已经利用$this->assign()赋值过了。所以这里才能显示出相应的信息

继续看上面这张图的实例，会发现{$vo.status}显示的是超级管理员和管理员，可是数据库中明明存储的是0和1。若想达到上面的显示效果，需要使用模型中的获取方法。

然后去看一下模型里面的代码是怎么写的：

model这个模型文件夹中的User.php，名字也不是瞎起的，这个User.php对应的就是数据库中的那个user表。我现在是知道了，上面的model中的User.php里的方法，是在其他页面的代码中调用的，这样才实现了对数据库的操作以及显示操作。我一开始误认为在这个文件中设置了方法，就自动生效，导致我无法理解代码的逻辑。

补充：上面的白色代码里面的成员属性，都是对应数据库中数据表的操作，每个成员属性设置是干嘛的，都可以在上面这幅图中找到相应的功能。

上面的白色代码是输出用户身份的，下面的代码是用户的状态

这个函数必须仔细看一下，写的精妙！这个函数通过获取到的值，与内部的关联数组进行比较，来决定返回什么汉字。可以想象，在其他页面调用这个函数的时候，肯定会先在函数外部获取到数据库的对应用户的static值，然后传进来，再放到其他模板中显示出返回值“已启用”或“已停用”

上面这个管理员页面红框框出来的部分，模板中的写法如下：

先是从session信息中，服务器告诉浏览器这个用户的名字叫admin，只有是admin的用户才能看到这部分的功能，/*那么我有一个疑问，假如我用burpsuite修改response呢？不对，无法修改，信息隐藏在session中，无法破解。除非能破解session对应的明文，否则无法修改session为自己想修改的样子。换句话说，如果不修改呢？（好吧，太深入了，太难了，能力不够）*/

编辑的功能是普通用户也能使用的，所以没有加判断标签。最后的删除功能，肯定只有超级管理员才能管理用户，因此也加了判断。

对应的函数的功能如下（函数是在admin_list.html下半部分）：

补充：
layer.confirm()就相当于是弹窗。
$.get(url,data,success(),dataType)，其中url代表目标地址，data代表请求发送到服务器的数据，success()代表请求成功时运行的函数，dataType是服务器响应的数据类型。上面只用了两个参数。其中url参数是必选，其他都是可选。另外，之前没搞懂{id:id}是什么鬼，仔细看了一下函数传入的形参id，这个{id:}应该是tp5的框架默认变量，这个默认变量为传入的形参id，就成了{id:id}，第二个id是形参，看颜色。这个形参传入的值是{$vo.id}。终于看懂了啊！哈哈！

上面函数的第二行代码又向后台请求setStatus方法了，我的天啊，还得继续跳转看函数功能！这个函数的功能编写的也有点绕人。

首先，服务器端脚本接收到浏览器端发过来的request请求，然后，服务器端从数据库中获取id那一栏所有数据

然后根据前端传过来的id去数据库值进行比对，看是否是超级管理员的id，若是，则将数据库的status值进行更新。

最后，又回到前端页面，继续往下看代码，这段代码是jquery的写法，我语法不熟悉，有点看不懂，得慢慢查资料：

好吧，这是涉及到样式的修改。。。超出我的学习范围了。不学这段代码了。知道就可以了。到时候动手做的时候，这里抄一下。

之后再看编辑按钮的前端函数是怎么写的

这个函数比较变态，传入了5个参数！

搞不懂传入长宽能干嘛。。。（可能是为了弹出窗口的大小）但是传入1是因为这个按钮是超级管理员才能用来编辑其他管理员的操作，而能看到这个按钮的都是超级管理员，因此直接传入参数1就可以了。

然而，服务器端接收到前端传过来的数据之后，设置了一通参数，渲染的居然是admin_edit页面。。。

为了配合好上面那张图，我还要研究一下他渲染的页面的前端是怎么写的。。。不然他的那些修改操作，比如名字之类的，是无法直接完成的。

再接着看删除操作，点击删除按钮，激活下面这个jquery脚本，向服务器端的deleteUser()方法发送请求，然后服务器端又是一通操作。。。前端又开始页面的样式修改，比如把某一行给删除之类的操作，这部分代码就抄一下吧。。。

接着上面这幅图请求的服务器端方法，如下：

回来继续看添加管理员按钮的操作（是上方的大按钮添加管理员，不是小按钮）

上面的添加操作，就是像下面这个函数发送的请求

这个函数渲染的居然是admin_add页面。。。哎，又是来回跳转

继续往下看，批量恢复那个大按钮是怎么写的

反正还是得向服务器端的方法发送请求，让服务器来决定如何操作。不管服务器有没有返回成功，按照他这个逻辑，都会弹窗“已恢复”

下面这个方法中，UserModel::update(参数一，参数二)，只有当参数二这个条件成立的时候，参数一才起作用。说的直白点，只有当is_delete=1的时候，才将delete_time赋值为null