php 怎么实现分页，如何使用jqueryeasyui分页插件？
1，引入必要的js,css文件。2，在html页面添加:
3，添加easyui分页插件到div中： $('#pp').pagination({ total:articleJSONArr.length,//总的记录数 pageSize:10,//每页显示的大小。 pageList: [10,20,50,100],//选择每页显示的记录数的下拉框的值。 onSelectPage: function(pageNumber, pageSize){//选择相应的页码时刷新显示内容列表。 //把请求的内容放入panel中。 var html=""; articleJSONArr.length/pageSize;//页数。 //i 开始的记录数 for(var i=(pageNumber-1)*pageSize; iarticleJSONArr.length? articleJSONArr.length:pageNumber*pageSize); i++) //遍历json; { html += "" + articleJSONArr[i]["数据库入库时间"] + "" + articleJSONArr[i]['文章标题'] + "
"; html += " "; } $("#pagecontent").html(html); //$("#frArticleDiv").prepend(html); //$('#content').panel('refresh', 'show_content.php?page='+pageNumber); }一开始想做java方面的？
我是15年毕业的学生，我觉得你现在既要学好学校的课程，又要做点项目，学会解决问题的思路，而不是只是会写代码，我大学的时候没有参与什么项目，除了毕业设计，这导致后来我再面试时失利，去了一家比较一般的公司，但是等我真的开始写代码时我才发现，大学学习的东西非常有用，告诉你计算机的起源，过程，解决问题的思路，我大二时和你一样迷茫，我到底是现在开始写代码呢，还是应该做什么？我遇到一个淘宝的资深开发人员来到我们学校讲课，我问他我最要紧的事情是干什么，是写代码吗？他回答说，打好基础，我问他什么是基础，他说计算机组成原理，计算机网络，编译原理，数据库等等一系列的课程，也就是大学所学的东西，我后来专心学本专业的东西，没有参与很多的项目，导致后来面试失利
我建议你认真学习本专业的东西，那些是计算机乃至现在大部分的技术基础构成，你只有很好的了解计算机运行的原理和过程才可以根据需求定制出方案，数据库这些基础知识要打下基础，但是现在又出现了文档型数据，大量数据的处理，凡事有问题，就必然会有人想出解决方案，你如果深究这些东西，就会发现和大学学的基础有关，无论是算法，还是处理思路，语言万变不离其宗，都是为了解决问题，完成功能，你理解了语言背后的思想以及原理，无论什么语言，掌握只是时间问题，java和c++的很多想法都类似，包括现在的前端语言JavaScript 都是不断的在优化，更符合设计思路，等你认真的打基础，会发现你学习这些语言，理解这些逻辑都十分快
总而言之，不要纠结，参与项目，亲自设计，培养自己解决问题的能力，提出设计方案的能力，以及开始要学会写文档，软件工程便教了这些，开始要会写可维护的代码，形成良好的注释习惯以及编写风格，多参与大学里面的项目，大创，这方便你找工作，但是真的想成为比较厉害的人，你必须了解计算机的基础
一个合格的web前端需要掌握哪些技术？
谢邀，我来分享作为BAT的web工程师看到的，一个合格的web前端需要掌握哪些技术。
三驾马车最基础的自然是JavaScript，HTML和css这三种语言。
首先了解下它们到底是什么。
HTML是用户看到的网页的骨架，比如你会发现当前页面分为左中右三个部分，其中还填充了不同的文字和图片；每个子部分还会继续细分，比如当前页面的中间部分下方有输入框等等。
CSS是网页展示的细节控制，比如你会发现有的文字是红底白色，有的子部分占了页面的二分之一宽，有的只占六分之一，有些部分需要用户进行某些操作（如点击，滑动）才会出现等等，这些就是有CSS来控制。
JavaScript是负责捕捉用户在浏览器上的操作，并与后端服务器进行数据交换的脚本语言。当用户在前端进行点击，输入等操作的时候，会触动绑定了该动作的JavaScript脚本，然后JavaScript收集数据，调用后端的api接口，再将后端返回的数据交给HTML和CSS渲染出来。
一个网页的HTML代码和CSS代码是可以直接在浏览器中查看的，你可以直接按F12，就能看到下图右侧的模块，左右侧红框就是代码与实际页面的对应关系。因此如果你看到某个网站的布局很不错，不妨点击F12，进行学习。
前端框架然而，实际应用中，已经很少有正规的项目组直接用上述三种语言进行web 前端开发了，而是使用很多封装了这三种语言的框架，比如
Vue.js
，angular，react native等等。它们是来自谷歌和Facebook的大神项目组，基于自己的经验，封装了原生前端语言，实现了更多更复杂更酷炫的功能。因此，可以说，学会使用这些框架，能达到事半功倍的效果。比如用了vue，它是自底向上增量开发的设计，其核心只关心图层，而且还可以与其他库或已存项目融合，学习门槛极其友好；另一方面，vue可以驱动单文件组件和vue生态系统支持的库开发的复杂单页应用。有了这个生态系统，可以说，vue是处在一个不断壮大，不断完善的欣欣向荣的状态。
网络通信协议由于前后端分离的趋势，前端还需要了解很多网络通信协议的知识，这里不局限于http协议，因为据我的经验，有时候我们还会用到websocket等协议。因此，前端需要简单了解不同协议的特点以及使用方式，但是好消息是不用像学习计算机网络课程一样对每种协议的原理都了解的特别透彻，只要学会如何用前端语言发送这种协议的请求就够了。
以上，如果对你有帮助，欢迎点赞或者留言~
我是苏苏思量，来自BAT的Java开发工程师，每日分享科技类见闻，欢迎关注我，与我共同进步。
怎样学习办公软件？
对于电脑初学者来说，刚开始接触办公软件会有些措手不及，那如何才能正确的使用Excel，希望接下来的一些皮毛会对大家有些帮助；
工具/原料一台电脑方法/步骤第一步，右击电脑桌面空白处，点击新建，将鼠标移动到Excel 工作表上，单击鼠标左键，这样一个新的工作表就新建完成了；
第二步，将鼠标移动到Excel 工作表图标上，右击会出现打开、打印、剪切、复制、重命名、删除等功能按钮，移动鼠标并点击相应命令即可对本工作表执行相应的操作；
第三步，双击打开或者执行“打开”命令，两者都可以打开本工作表；
第四步，假如在使用过程中，担心因电脑突然断电而导致数据丢失，可以打开“选项”→“常规与保存”→“定时备份，时间间隔最短1分钟”，这样可以解决此问题；
第五步，假如我们是在原有工作表的基础上进行修改，但是又不想改变原工作表内容，我们可以采用“另存为”命令来完成本操作；
第六步，假如我们想把工作表内容转化为PDF格式，可以按如下操作：“另存为”→“输出为PDF格式”→“确定”→导出完成，（注：本功能仅对高版本适用）
步骤阅读另外小编建议大家再下载一粒云盘，进行文件存储管理，办公必备不可缺的一部分注意事项办公软件必须是07以上的高版本哦。什么样的代码叫好代码？
送大家以下java学习资料
简介： 我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
一句话概括衡量代码质量的唯一有效标准：WTF/min —— Robert C. Martin
Bob大叔对于好代码的理解非常有趣，对我也有很大的启发。我们编写的代码，除了用于机器执行产生我们预期的效果以外，更多的时候是给人读的，这个读代码的可能是后来的维护人员，更多时候是一段时间后的作者本人。
我敢打赌每个人都遇到过这样的情况：过几周或者几个月之后，再看到自己写的代码，感觉一团糟，不禁怀疑人生。
我们自己写的代码，一段时间后自己看尚且如此，更别提拿给别人看了。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。—— Martin Fowler
所以，谈到好代码，首先跳入自己脑子里的一个词就是：整洁。
好的代码一定是整洁的，给阅读的人一种如沐春风，赏心悦目的感觉。
整洁的代码如同优美的散文。—— Grady Booch
好代码的特性很难给好的代码下一个定义，相信很多人跟我一样不会认为整洁的代码就一定是好代码，但好代码一定是整洁的，整洁是好代码的必要条件。整洁的代码一定是高内聚低耦合的，也一定是可读性强、易维护的。
高内聚低耦合
高内聚低耦合几乎是每个程序员员都会挂在嘴边的，但这个词太过于宽泛，太过于正确，所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣：
开闭原则 OCP (The Open-Close Principle)单一职责原则 SRP (Single Responsibility Principle)依赖倒置原则 DIP (Dependence Inversion Principle)最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
里氏替换原则 LSP (Liskov Substitution Principle)接口隔离原则 ISP (Interface Segregation Principle)组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)这些原则想必大家都很熟悉了，是我们编写代码时的指导方针，按照这些原则开发的代码具有高内聚低耦合的特性。换句话说，我们可以用这些原则来衡量代码的优劣。
但这些原则并不是死板的教条，我们也经常会因为其他的权衡（例如可读性、复杂度等）违背或者放弃一些原则。比如子类拥有特性的方法时，我们很可能打破里氏替换原则。再比如，单一职责原则跟接口隔离原则有时候是冲突的，我们通常会舍弃接口隔离原则，保持单一职责。只要打破原则的理由足够充分，也并不见得是坏的代码。
可读性
代码只要具有了高内聚和低耦合就足够好了吗？并不见得，我认为代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该是可读性很强的。可以从以下几个方面考虑整洁代码，提高可读性。
命名
大到项目名、包名、类名，小到方法名、变量名、参数名，甚至是一个临时变量的名称，其命名都是很严肃的事，好的名字需要斟酌。
► 名副其实
好的名称一定是名副其实的，不需要注释解释即可明白其含义的。
/** * 创建后的天数 **/ int d; int daysSinceCreation;
后者比前者的命名要好很多，阅读者一下子就明白了变量的意思。
► 容易区分
我们很容易就会写下非常相近的方法名，仅从名称无法区分两者到底有啥区别（eg. getAccount()与getAccountInfo()），这样在调用时也很难抉择要用哪个，需要去看实现的代码才能确定。
► 可读的
名称一定是可读的，易读的，最好不要用自创的缩写，或者中英文混写。
► 足够短
名称当然不是越长越好，应该在足够表达其含义的情况下越短越好。
格式
良好的代码格式也是提高可读性非常重要的一环，分为垂直格式和水平格式。
► 垂直格式
通常一行只写一个表达式或者子句。一组代码代表一个完整的思路，不同组的代码中间用空行间隔。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
如果去掉了空行，可读性大大降低。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
类静态变量、实体变量应定义在类的顶部。类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。
► 水平格式
要有适当的缩进和空格。
► 团队统一
通常，同一个团队的风格尽量保持一致。集团对于 Java 开发进行了非常详细的规范。（可点击下方阅读原文，了解更多内容）
类与函数
► 类和函数应短小，更短小
类和函数都不应该过长（集团要求函数长度最多不能超过 80 行），过长的函数可读性一定差，往往也包含了大量重复的代码。
► 函数只做一件事（同一层次的事）
同一个函数的每条执行语句应该是统一层次的抽象。例如，我们经常会写一个函数需要给某个 DTO 赋值，然后再调用接口，接着返回结果。那么这个函数应该包含三步：DTO 赋值，调用接口，处理结果。如果函数中还包含了 DTO 赋值的具体操作，那么说明此函数的执行语句并不是在同一层次的抽象。
► 参数越少越好
参数越多的函数，调用时越麻烦。尽量保持参数数量足够少，最好是没有。
注释
► 别给糟糕的代码加注释，重构他
注释不能美化糟糕的代码。当企图使用注释前，先考虑是否可以通过调整结构，命名等操作，消除写注释的必要，往往这样做之后注释就多余了。
► 好的注释提供信息、表达意图、阐释、警告
我们经常遇到这样的情况：注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了，而注释并没有跟进变化。所以，注释最好提供一些代码没有的额外信息，展示自己的设计意图，而不是写具体如何实现。
► 删除掉注释的代码
git等版本控制已经帮我们记录了代码的变更历史，没必要继续留着过时的代码，注释的代码也会对阅读等造成干扰。
错误处理
► 错误处理很重要，但他不能搞乱代码逻辑
错误处理应该集中在同一层处理，并且错误处理的函数最好不包含其他的业务逻辑代码，只需要处理错误信息即可。
► 抛出异常时提供足够多的环境和说明，方便排查问题
异常抛出时最好将执行的类名，关键数据，环境信息等均抛出，此时自定义的异常类就派上用场了，通过统一的一层处理异常，可以方便快速地定位到问题。
► 特例模型可消除异常控制或者 null 判断
大多数的异常都是来源于NPE，有时候这个可以通过 Null Object 来消除掉。
► 尽量不要返回 null ，不要传 null 参数
不返回 null 和不传 null 也是为了尽量降低 NPE 的可能性。
如何判断不是好的代码讨论了好代码的必要条件，我们再来看看好代码的否定条件：什么不是好的代码。Kent Beck 使用味道来形容重构的时机，我认为当代码有坏味道的时候，也代表了其并不是好的代码。
代码的坏味道
► 重复
重复可能是软件中一切邪恶的根源。—— Robert C.Martin
Martin Fowler 也认为坏味道中首当其冲的就是重复代码。
很多时候，当我们消除了重复代码之后，发现代码就已经比原来整洁多了。
► 函数过长、类过大、参数过长
过长的函数解释能力、共享能力、选择能力都较差，也不易维护。
过大的类代表了类做了很多事情，也常常有过多的重复代码。
参数过长，不易理解，调用时也容易出错。
► 发散式变化、霰弹式修改、依恋情结
如果一个类不是单一职责的，则不同的变化可能都需要修改这个类，说明存在发散式变化，应考虑将不同的变化分离开。
如果某个变化需要修改多个类的方法，则说明存在霰弹式修改，应考虑将这些需要修改的方法放入同一个类。
如果函数对于某个类的兴趣高于了自己所处的类，说明存在依恋情结，应考虑将函数转移到他应有的类中。
► 数据泥团
有时候会发现三四个相同的字段，在多个类和函数中均出现，这时候说明有必要给这一组字段建立一个类，将其封装起来。
► 过多的 if...else 或者使用 switch
过多的 if...else 或者 switch ，都应该考虑用多态来替换掉。甚至有些人认为除个别情况外，代码中就不应该存在 if...else 。
总结本文首先一句话概括了我认为的好代码的必要条件：整洁，接着具体分析了整洁代码的特点，又分析了好代码的否定条件：什么样的代码不是好的代码。仅是本人的一些见解，希望对各位以后的编程有些许的帮助。
我认为仅仅编写出可运行的代码是远远不够的，还要时刻注意代码的整洁度，留下一些漂亮的代码，希望写的代码都能保留并运行 102 年！
后续增加一些实际的例子来说明好的和坏的代码；分享下如何编写整洁代码——自己认为有用的一些编程技巧。