PHP – EasyUI DataGrid 资料取的方式介绍

EasyUI DataGrid 是一个用 Jquery 写的 DataGrid，由此可知，是一个 前端 Web UI 技术，一般大家在产生 DataGrid 比较常见的应该就是使用后台 PHP 等后台语言，来直接产生 HTML 语法，来显示 DataGrid，当要对该 DataGrid 操作时，在传递参数到后端，重新产生整各网页。

而 EasyUI DataGrid 支援两种做法，一个是，上述，后台 server 把显示的 HTML 产生好，在给前端显示。另一种是，利用 AJAX 的方式来产生，就只是单纯喂 JSON 格式资料给前端，前端接收到资料后，在自己分析资料利用 JQuery 来刷新 DataGrid 该部分的画面。

这边介绍的是第二种做法，利用 AJAX 技术来做，这样的好处，是可以把 资料层-> 控制层-> 展示层 三层独立来运作，达到我在之前 多层次架构设计前言 所讲的精神，不会像老方法，把 HTML 的产生都放在 PHP 中来产生，造成 PHP 开发人员本身，也要对 HTML 等前端技术也要了解很深才能进行开发的问题。

在来如此作法，为带来另一种好处，就是你前端的 UI 是可以更换，而后台程式却不用来大幅修改。目前支援 JSON 资料格式的 JavaScript DataGrid 有很多各，大家也可以多去参考其他的公司所提供的 DataGrid ，从中选择一个最适合的来使用。

介绍到此，接下来直接看程式码，会更加了解我上述的意思：

首先，需要先设计 HTML UI 介面，定义要显示哪些栏位，栏位的显示名称等，关于这部分的栏位定义，EasyUI DataGrid 也是有提供，使用 JavaScript 来动态定义，而我习惯用 HTML 直接定义，这样 也不复杂，后面在分工上，也比较容易来直接交给 Web 美工人员来直接操作。

这部分重点在 URL 的设定。
DataGrid2.php

复制代码 代码如下:

一條小龍 easyUI datagrid url test

url="datagrid2_getdata.php" title="Load Data" pagination="true">

UNum	User ID	Password	Birthday	Nickname	DBSTS

在来定义资料取得的后台介面
datagrid2_getdata.php
复制代码 代码如下:
$page = isset($_POST['page']) ? intval($_POST['page']) : 1;
$rows = isset($_POST['rows']) ? intval($_POST['rows']) : 10;
$offset = ($page-1)*$rows;
$result = array();

$tablename = "STUser";
// ...
require_once(".\db\DB_config.php");
require_once(".\db\DB_class.php");

$db = new DB();
$db->connect_db($_DB['host'], $_DB['username'], $_DB['password'], $_DB['dbname']);
$db->query("select count(*) As Total from $tablename");
$row = $db->fetch_assoc();

$result["total"] = $row["Total"];

$db->query("select * from $tablename limit $offset,$rows");

$items = array();
while($row = $db->fetch_assoc()){
array_push($items, $row);
}
$result["rows"] = $items;

echo json_encode($result);
?>

由上述，可以看出，这是一个很单纯的资料取得的动作。
一开始 DataGrid 会传进来 两个参数，
$_POST['page']) 目前是在第几页
$_POST['rows']) 每页要显示几笔资料

然后，要使用一个阵列 $result ，存放两个资讯，
$result["total"] 有几笔资料
$result["rows"] 存放实际的资料阵列集
最后要将 $result 阵列，产生将 JSON 资料格式来输出，DataGrid 接收到以后就会来处理、刷新画面了。

后面，在更进一步，可以将 datagrid2_getdata.php 在抽象化一层，也就是将属于 EasyUI DataGrid 特有的资料格式处理的部分与资料库存取的的部分分离，各自独立出来成为 两个 class 来处理。

一个好的架构 以及 class 设计，其实都是靠经验的累积而生成的，不断演进改良，原有的框架，其中最重要的精神就是，每个 Class 的分工要清楚而且精确，这是为了应付上述，不断演进 这各问题来做的对应措施，这样在未来才更容易去做修改调整。

否则更容易变成，你想改却不知从何下手，因为一改就有几十支，甚至上百支程式等着你，要一起修改，从而延伸出，稳定性问题，也就是大家反对去修改原有系统，就是因为 太多要改了，少改一支也不行，问题几十支一起改，就算都改完，谁来测试有没有改好，难道叫你的 user 来帮你测，想想，就还是算了，不要再改了，反正现在系统也都还好好的可以用。