关于beetl认识的几个误区
Beetl缺少文档
如果搜索beetl教程和文档,你会发现基本上只能定位到beetl官网文档和作者写的少量beetl使用说明,不能认为beetl使用者少才导致的。这恰恰说明了beetl官网文档写的够用,且社区提供了各种demo以及及时的问题回答。相比较JSP,Freemaker那种连一个循环如何使用都有无数文章,无数作者孜孜不倦的对这些简单概念写文章说明。Beetl确实没有这样的文章,甚至也没有视频。Beetl语法上基于了JS,而且本来就是国人研发的,文档,交流都没有什么困难
Beetl使用了<%%> , 像jsp,非常难看。
这也是误区,事实上,beetl定界符可以允许任意符号,比如类似PHP的<? ?> ,类似html注释的<!--# -->,或者简单的 @和回车换行符号配对,如下代码
@ for(u in userList){ <span>${uLP.index}: ${u.name}</span>@}
Beetl的语法像Java
Beetl语法参考了javascript,因此,从形式上看确实像Java,这也是Beetl学习曲线低的原因。但Beetl作为一个模板语言,专门用于输出,比基于Java的JSP好很多,比如上一段代码,uLP是一个内置的循环变量,可以获得当前索引,奇偶行等信息,只需要在循环变量后加上LP就可以了,这就是专门针对模板输出用的。另外,beetl支持elsefor,如上代码,没有进入循环体,可以使用elsefor做说明
@for(){ @}elsefor{ <span> 无记录 </span> @}
Beetl 模板语言为模板定制的特性还有如下:
省略的三元表达式
安全输出
select-case 语法
html 标签
格式化输出
直接调用java方法或者属性
多种布局函数
模板变量
严格MVC控制
这些语法都是模板特供的语法,完全跟java是俩回事情
更喜欢指令式,而非脚本式模板语言。
类Velocity这样的指令式模板语法有人更喜欢,原因是指令少。但是缺点也明显,再应对复杂的逻辑渲染的时候,往往更难看和难易书写。beetl是脚本式的模板引擎,语法可能相对较多,但基于JS,并不难理解,脚本式的语法在应对复杂渲染逻辑的时候也更得心应手点。 不要被指令式模板引擎的 helloworld例子所迷惑,看起来爽,但用在项目里,最后跟脚本式是一样的。
模板性能不重要
也在网上见到过认为与其优化模板引擎,还不如优化数据库访问这么一说,我觉得说的是对的,要是我也会先考虑优化数据库访问等地方,但如果这些都优化好了,也可以在用更好的模板引擎提升行性能 ,beetl性能6倍于freemaker,2倍于JSP(也有三方测试3倍于JSP,可能是JSP是用了过多JSTL导致的),模板引擎涉及CPU计算,以及IO输出,其实是在Web应用中,较为消耗资源的一块。我以为,如果能降低这块消耗,对系统性能提升还是有效果的。如果你的数据库访问已经优化的很好,业务代码已经写的很完美,为什么不能使用性能更好的模板引擎呢,beetl又不需要做什么额外的操作才能达到性能极致,他本来就有很好的性能。
后端模板引擎不重要了
这个是事实,现在前端模板引擎越来越重要,beetl 也开发了一个beetljs,但因为体积庞大,相比那些7K,8K的模板引擎,实在拿不出手,所以一直没有推出。只能以后再优化体积,缩减语法特性再选择时机推出。
就算趋势如此,但我认为后端模板引擎还是有其优点的,目前还是很重要:
后端模板引擎功能,可维护性等远远强于前端模板引擎
后端模板引擎位于后端,因此获取后端数据得心应手,而前端模板引擎需要准备所有数据
后端模板引擎应用范围广:还有代码生成,静态页面生成,后端的一些模板功能,如发送邮件,短信等
在大部分公司前端人才缺乏,使用前端模板引擎会导致更多的人集中到前端。公司在没有准备好这一变化前尽量少使用前端模拟板引擎
开发效率来讲,后端模板引擎流行多年,因此,应该比前端模板引擎开发效率更高
后端模板引擎适合SEO优化,前端模板引擎则很难
后端模板引擎有布局功能
我觉得当前使用模板引擎的正确姿势是前端+后端结合使用,当然前端模板引擎现在也在借鉴后端模拟引擎功能,会越来越完美, 说不定哪天真的会在web应用中占主导地位。而且面向架构的服务,移动端的广泛使用,前端模拟引擎是确实越来越重要
上一篇: vector的erase操作
下一篇: Spring事务抽象