PHP里面的数据的分页处理算是每一个phper必须会的东西了，大家日积月累下来也基本都有一套自己喜欢用的分页程序。
这几天看了一些的个人框架，还有网上蛮多的个人分页程序发现一些共同的特点：
1、分页程序里面继承大量的数据库操作。少至一些DB Query 的 WHERE、ORDER，大致整个数据库的东西。基本上把分页当做一个数据处理模块来做了。
如果一套框架（程序）里面没有特有的数据库处理模块，这样也可以省大半精力花在分页上，如果有比较独立的数据库类（模块）了，再把分页也混进去就不好了。
2、还有就是那些个人分页基本上都是把固有的语言、编码、HTML结构代码甚至是javascript集成进去了，这个兼容性、移植性上就不太行了。
3、最后一个就是分页里面对于REQUEST请求的处理，基本上分这两类：一是将全部变量传递进入分页模块，然后在分页模块里面组合生成分页链接需要的URL，另外一种就是在分页模块里面调用REQUEST自行组合变量。
这样写法虽然不能说不好，但是如果作为一个比较大的、常用的功能模块库来看待的话，上面的几点就成了比较大问题了
首先继承数据库操作这个是非常愚蠢的，且不说这样写不兼容不同的数据库驱动，分页里面的SQL执行效率、异常处理、代码安全也存在比较严重的问题。本来这些不是分页该做的事情却成了分页要承担的责任问题 >__<
把HTML、javascript写进一个模块，这个对于大家整天提到的MVC架构来衡量就知道怎么回事了。 一个分页的显示方式不是由MC控制的，而是由V（模板）来控制的。 你把那些标记都写死了，换模板，你的结构不够用怎么办？？ 有扩展方式么？ 有接口么？javascript的兼容有时候都会是一个问题。
曾经就遇到这么一个系统：同时开放WML、HTML两种模板。。。集成HTML的方法难道要写全这两种的方式么？ 哈哈。。遇到其他的还要写其他的。一些更恐怖的就是把 分页的css都写进去了。 这个更猛。。。。后面搞样式的人不会还要去改写程序吧？？？？
对于处理请求这个问题与集成数据库操作一样，都不应该是分页模块处理的东西，集成进去了。哪天需要 URL_REWRITE就不行了。
因此个人对分页的看法就是：
分页只需要处理的参数有：查询结果总数、每页数量、当前页（可以默认配置一个REQUEST KEY，这样还是比较方便的，不过必须把它当成缺省配置），
产出的话：分页的信息集合
提供的接口：产生URL，使用扩展模板、扩展语言库，提供语言、模板配置参数接口····