锁定老帖子 主题:FreeMarker和Jsp的应用范围
精华帖 (4) :: 良好帖 (2) :: 新手帖 (1) :: 隐藏帖 (2)
|
|
---|---|
作者 | 正文 |
发表时间:2009-11-18
最后修改:2009-11-18
最近要做新项目,想了解一下新的技术看看有没有可以改进的地方。于是学习了一下Struts2(之前一直用Struts1),接触到了FreeMarker,做了一些实验之后,对其功能很是疑惑。
从我自己测试以及看网上大家的评论可以得出FreeMarker具备以下优点:
我认为FreeMarker可以应用在以下场景: 3、后台动态文档生成,如群发邮件模板生成个性邮件。
任何技术都有他的适用范围,抛砖引玉,希望FreeMarker有丰富经验的兄弟多说说自己是如何使用FreeMarker的,以及使用中的一些优点和问题。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-11-19
没有兄弟想讨论一下这个问题么?还是我放错了版面..
|
|
返回顶楼 | |
发表时间:2009-11-19
不是所有的数据处理都需要放在Action中的,引入ViewBean层接收Action传过来的数据,处理后发给显示层。另外我对所谓的速度快也持怀疑态度,大量反射的应用不可能比原生jsp快的。
|
|
返回顶楼 | |
发表时间:2009-11-19
servlet 一样可以很容易的和Freemarker结合在一起,比如下面的: 很轻的,Servlet + Freemarker 组合体,没有那么硬~url: http://yongboy.iteye.com/blog/513764
Servlet代码没有变化,Freemarker轻易的取代了JSP。这是一种组合方式,没有显示在程序代码里面声明使用了Freemarker。
|
|
返回顶楼 | |
发表时间:2009-11-19
lz还要多加研究啊~ 在多用用会有新的体会 我每次都是一段时间以后推到我以前的想法 可能是我太初级了吧
|
|
返回顶楼 | |
发表时间:2009-11-19
对于通常的SSH框架来说,选择freemarker还是jsp是同样的方便。
freemarker和jsp不是逻辑分离的原因,还只不过是个手段。我通常是在生成html页面中使用jsp,而生成xml时使用freemarker,这样感觉思路清淅点,jsp代表着一个页面,而freemarker通常用于生成请求的数据。但是,两者是共通的,jsp也可以生成xml文件,freemarker也可以生成html页面。不过,jsp的IDE作为页面展示时,IDE的支持会好点。 还有个很大不同之处,在于freemarker的表达式语法很适合用于数据展示,而jsp做为数据处理时通常要借用jstl等标签库。 |
|
返回顶楼 | |
发表时间:2009-11-19
需要考虑几个问题。
1。view层真的需要调用JAVA程序吗? 首先view不应该调用business代码,最多是调用一些格式化的代码。那么只要能实现一个格式化的框架就能使view完全和java无关。 2.如果技术要看美工的DreamWeaver代码那还叫技术和美工分离吗? 3。4。5。是不相上下的。 |
|
返回顶楼 | |
发表时间:2009-11-19
相比之下,FM的优点:
FM的macro很强大,类似Method。LZ试着在JSP里面写一个Method试试。 FM是一种模板语言,而生成的文本是用来UI展示呢,还是本身就生成文本文件,FM是不理会的;但是JSP不同,需要Sevlet容器,并且只能用于Web。 FM的错误提示很强大,不像JSP一样,还需要看编译成Servlet的代码才能看出是什么错误。 FM的缺点: 没有好的IDE支持,JBoss的FreemarkerIDE提示有限,而且不能预览 至于性能,估计FM和JSP应该差不多。 |
|
返回顶楼 | |
发表时间:2009-11-19
引用 1、逻辑分离,无非是FreeMarker模版无法直接运行Java代码,强制要求所有数据必须预处理才能将结果传入View层做最终展现。我个人对这种过于纯粹的东西报以怀疑,实际工作中很多时候这种纯粹的逻辑分离很难实现。当一个长期维护的项目,不断增加显示逻辑之后,为了保持View层的这种强制的干净,而在Action层增加大量处理逻辑,我不觉得维护性会好(也许我理解错了,毕竟没有长期使用过)。就像前些年流行XML配置文件,分离了逻辑,后来发现太麻烦,又产生了Annotation消灭XML配置文件,无论分离还是聚合,逻辑是无法消灭的,总是要有一个地方放。所以到底是多写一些代码来保证View层看上去很美,还是把显示逻辑全写到View层,谁又能真正说清楚哪个更好。 我们到今天很多项目还在用最传统的Jsp,也还在用<%%>,也会有比较多的Java代码出现在Jsp页面上的情况,但是页面上的代码全都是显示相关的逻辑,都是最简单的Java代码,会Java的就能维护,学习成本基本为0,维护岂不是更好?更符合KISS原则。 业务逻辑与视图展示分离思维在目前来讲,是大家比较认可和赞成的。如果你认为在JSP写<%%>是一种很HAPPY的事情,恐怕同意你的兄台不是太多,J2EE的开发中分层的目的就是减少开发、维护的成本,使系统的结构更加清晰优美,这点你同意吗? 引用 2、美工和技术工作分离,我一直觉得这只是一个神话。到今天为止,我们公司美工和开发的合作方式基本是美工做界面原型图,把需要的图片切割出来,把需要的效果制作成CSS交给技术,技术按照需要的效果进行编码制作HTML静态原型界面。因为,对于稍微复杂一点的页面,我相信没有哪个技术能忍受美工直接用DreamWeaver生成出来的代码。 这个不是神话,很多公司都可以做到,在多种视图技术(JSP(Sitmesh,Tiles)、Freemarker、Velocity、Facelets等等)的支持下,已经可以做到美工就是改改Css和Image,程序员只顾着自己垒垒砖头就OK~~但是完全不交互是不可能的~ 引用 3、速度快,算个优点吧,但是没有那么重要吧,对于现在的机器一般的Jsp编译也就一两秒钟的事情。多数的时间还是花在编写和测试上的。 速度吗,其实不是很快,我的测试没有JSP快,但是慢的也不多。 引用 4、可以在IDE中运行,这个也算个小优点,但是界面开发更多时候还是以最终显示效果来进行测试的,毕竟比较直观。直接从生成的HTML找需要的信息和刷新一下浏览器看结果哪个更高效? 支持Freemarker的IDE很成熟,比如Intellij IDEA、Eclipse,不过自定义的宏需要一些额外的修改,在IDEA中修改Template Files可以让Freemarker的提示更高效。 引用 5、Macro,这个没有太多使用经验,就不做评论了,但是可以确定Jsp一定也能实现。 这个嘛。就是谁用谁知道了,不包治百病但是绝对有效!=.= |
|
返回顶楼 | |
发表时间:2009-11-19
引用 、Macro,这个没有太多使用经验,就不做评论了,但是可以确定Jsp一定也能实现。
jsp还真没有办法实现
|
|
返回顶楼 | |