js模板最本质的作用是【变静为动】
一切利用这方面的都是优势,不利于的都是劣势。
- 可维护性(后期改起来方便);
- 可扩展性(想要增加功能,增加需求方便);
- 开发效率提高(程序逻辑组织更好,调试方便);
- 看起来舒服(不容易写错);
从以上四点,你仔细想想,前端模板是不是无论从哪方便优势体现都不是一点两点。
我之前在写一个输入联想控件的时候,改过好几个版本,每个版本不是因为性能不好就是因为代码凌乱而被推翻,最后用了understore模板引擎,效果有明显改善。整好这两天在研究互联网技术架构,发现很多的开发框架前端都是使用js模板引擎,感悟真的是大道至简,殊途同归啊,哈哈。
关于为什么使用js模板引擎,在博客园发现园友的一片文章《js模版引擎handlebars.js实用教程——为什么选择Handlebars.js》,该文已经做了详细解答。下面内容转自该文:
据小菜了解,对于java开发,涉及到页面展示时,比较主流的有两种解决方案:
1. struts2+vo+el表达式。后端模板引擎
这种方式,重点不在于struts2,而是vo和el表达式,其基本思想是:根据页面需要的信息,构造出一个实体,这个实体中包含了界面需要的所有属性,通常这个实体是由N个表中的字段构成的,俗称vo。由于vo的属性可以是String、List、Map等等等,又可以vo套vo,因此这种方式非常灵活,也非常好用。
在后台对vo进行赋值,通过struts2封装到request中,然后在界面用el表达式,通常是${}、forEach标签什么的,即可构造出界面。
但这种方式小菜却不是很看好。因为这种利用标签控制html,依然是把表现和控制混杂在一起,html里边混杂了大量el控制标签,很不美观。
当然,小菜不可能因为这么简单的理由拒绝这种方式,读者仔细思考可以发现,利用el表达式生成html代码,这是一个在服务器端执行的动作,在服务器端解析完成之后,才发送到客户端浏览器上,这样做会占用大量服务器资源,而且速度缓慢。
示例代码:
<c:forEach var='bm' items="${contractAuditVo.borrowerModels}"> <table> <tbody> <tr> <td>借款人编号:</td> <td> <p> ${bm.borrowerId } </p> </td> </tr> <tr> <td>客户编号:</td> <td> <p> ${bm.customerId } </p> </td> </tr> <tr> <td>曾用名:</td> <td> <p> ${bm.usedName } </p> </td> </tr> </tbody> </table> </c:forEach>
2. Json+ajax+拼html。 常规字符串模板引擎
这种方法一般是基于ajax请求,要求服务器端返回一个json类型的json字符串,这个json串中包含了界面所需的所有信息,界面拿到json串后,构造出html,完成界面展示。
小菜推荐这种方法,通过这种方式编写的页面,反应速度非常快,用户体验非常好。
因为服务器端只需要提供一个json串,由客户端完成解析,因此服务器承受的压力很小,目前的电脑配置都较高,客户端的浏览器解析js脚本很快,因此页面体验效果好。
解析的过程大致是通过Jquery的each方法,进行遍历。
但是小菜利用这种方式时,犯了一个致命的错误,小菜是通过原始的拼接html的方式,页面中写了大量html+=”<div>”;,这种写法使页面变得非常凌乱,几乎不可以维护。
示例代码:
var contractTextHtml=""; $.each(jsonObject.cl,function(i,n){ contractTextHtml=""; //插入合同文本数据 contractTextHtml+="<div title='出借人信息---"+hiddenNull(n.cm.lenderName)+"' style='overflow:auto;padding:5px;'>"; contractTextHtml+="<table class='ui-table ui-table-noborder'>"; contractTextHtml+="<tbody>"; contractTextHtml+="<tr><td>合同编号:</td><td><p>"+hiddenNull(n.cm.contractId)+"</p></td></tr>"; contractTextHtml+="<tr class='ui-table-split'><td>出借人姓名:</td><td><p>"+hiddenNull(n.cm.lenderName)+"</p></td></tr>"; contractTextHtml+="<tr><td>出借人证件类型:</td><td><p>"+hiddenNull(n.cm.lenderIdType)+"</p></td></tr>"; contractTextHtml+="<tr class='ui-table-split'><td>出借人证件号:</td><td><p>"+hiddenNull(n.cm.lenderIdNum)+"</p></td></tr>"; contractTextHtml+="<tr><td>出借金额:</td><td><p>"+hiddenNull(n.cm.lenderAmount)+"</p></td></tr>"; contractTextHtml+="<tr class='ui-table-split'><td>出借人编号:</td><td><p>"+hiddenNull(n.cm.lenderNo)+"</p></td></tr>"; contractTextHtml+="<tr><td>出借人银行帐号:</td><td><p>"+hiddenNull(n.cm.lenderBankAccount)+"</p></td></tr>"; contractTextHtml+="<tr class='ui-table-split'><td>撮合编号:</td><td><p>"+hiddenNull(n.cm.makeMatchNo)+"</p></td></tr>"; contractTextHtml+="</tbody>"; contractTextHtml+="</table>"; contractTextHtml+="</div>"; $("#textList").append(contractTextHtml); });
造成这种问题的根本原因在于拼接html打乱了html原有的层次结构,看不出来哪里是哪里,没有了层次结构的代码,堆在那里就像是一坨垃圾。
el表达式构造html优点是能够保持html原有格式,js构造html优点是速度快省资源,为什么我们不能把二者的优点结合在一起呢?这就是Handlebars.js。
既然要在项目中引入js模版引擎,就必须进行技术选型,严格考核之后,才可以引入,就好像是木桶效应,不能让他成为项目中的短板。
Handlebars.js是一款基于Jquery的插件,以json对象为数据源,支持逻辑判断、循环等操作,同时具有非常好的扩展性,体积60KB左右,经过小菜仔细的分析研究,这是一款不可多得的js模版引擎。
包括一些mvvm前端框架自带的模板输出模块,如:vue.js、Angular.js----------Dom模板引擎效果很好