其实,JSF和Tapestry也并不是那种头碰头的相同竞争性技术,两者还是各有侧重点的,不过比较细微,但是这种细微点在实现一个大工程时可能带来不同的感受和变化。
成都创新互联公司2013年成立,是专业互联网技术服务公司,拥有项目网站制作、成都网站制作网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元馆陶做网站,已为上家服务,为馆陶各地企业和个人服务,联系电话:13518219792
首先,我们从一个高度来抽象一下表现层框架应有的技术架构,下图可以说所有表现层框架技术都必须实现的功能架构图:
当然,我们不必废话罗嗦MVC模式,MVC模式是基准模式,现在框架技术已经不必再拼是否是MVC模式了。 在上图MVC模式基础上,一个表现层框架无外乎要实现图中的三个功能:
1.在当前页面能够显示一个组件对象的内容;而不是象纯JSP那样,需要在Jsp页面写入“调用对象方法”的Java代码。
2.当用户按下页面的提交按扭或链接后,事件发生,这时应该触发服务器端并将当前页面的参数提交给服务器。这种机制表现在Form表单提交和有参数的链接
3.从一个页面视图直接跳转到另外一个页面视图,单纯的导航作用。
我们通过下表来比较这 三种框架在实现上图各个功能时技术细节,从而得出他们的异同点和偏重点。
Struts | Tapestry3.0 | JSF | |
在View显示的组件要求 | 组件必须继承ActionForm | 分显式调用和隐式调用 组件必须继承BaseComponent |
普通POJO 无需继承 Managed Bean |
组件在View显示粒度 | View页面只能显示与表单对应的ActionForm,配置中Action ActionForm 页面一般只能1:1:1关系。 | 可将组件嵌入页面任何一行,对使用组件数量无限制。 | 同Tapestry |
页面分区tiles | 使用Tiles标签库实现,需要另外tiles-def.xml配置文件 | 组件有自己的视图页面,通过调用组件即直接实现多个页面组合。强大自然的页面组合是其特点。 | 通过组件+标签库实现Subview,但如需重用Layout,还要结合Tiles. |
页面跳转 | 使用标签库html:link中写明目标URL,URL名称需要对照配置文件的path命名,与组件Action耦合。 | URL名称是目标的组件名称,不涉及URL和路径等操作,方便稳固。 | 通过组件+标签库实现Subview,但如需重用Layout,还要结合Tiles. |
参数传递 | 使用html:link时传递参数超过一个以上处理麻烦。 | 直接调用组件,直接赋予参数,没有参数个数限制 | 参数分离传递给组件 |
事件触发 | 通过表单提交submit激活,不能细化到表单里字段。 | 能够给于表单每个字段贴一个事件,事件组件必须实现PageListener接口 | 同Tapestry,事件组件必须实习ActionListener 接口 |
Struts组件编程模型
Struts实现组件编程时有一些复杂:经常为一个页面中需要引入多个组件而头疼,因为Struts中无法直接引入多个组件,必须绕一些圈子:
一般分两种情况:如果同一个Action就可以对付这些组件,那么在这种情况下有两个办法:
1.将这多个组件装入一个ActionForm中,如使用MapForm等机制;
2.手工将多个组件装入request/session等scope中,然后根据其名称在jsp中获得。
这两个方法都有缺点: ***种办法经常一个ActionForm弄得面目全非,变成一个大杂烩,违反了OO分派封装的原则;第2种办法其实又回到jsp编程;
第二种情况,如果这些组件必须有预先由不同的Action来处理,每个组件必须经过Action -->ActionForm流程,在这种情况下有两种办法:
1.使用Tiles, 不同流程输出到同一个页面的不同区域。是一种并行处理方式。
2. 对多个流程首尾相连,***Action forward结果是第二个Action,***输出一个Jsp,在这个jsp中就可以使用前面多个流程的多个ActionForm了,这属于串行方式。
Struts组件模型缺点
Struts组件编程必须限定在Action/ActionForm/JSP这三个框框中做文章,难度相对比较大,而Tapestry/JSF则没有太多这些技术框框限制,两者在组件编程方面更让编程者自由一些,方便一些,这也是组件型框架的优势吧。
Struts标签库
在Struts中,经常需要使用标签库来显示组件ActionForm中内容,这就涉及到一个结合的问题,标签库是别人写的,参考Struts的标签库用法,而组件是自己的,难度和麻烦就体现在这个结合点上。
JSF基本思路和Struts差不多,只不过换了不同标签库,也需要标签库+组件的结合思考,不过因为组件这里是通用组件,没有什么限制,所以这样比Struts要轻松一些。
Tapestry使用了组件库概念替代了标签库,没有标签库概念,这样就没有标签库和自己的组件需要结合的问题,都是组件的使用,组件中分Tapestry标准组件和自己定义的组件,这也是接触了Jsp体系的人学习Tapestry面临的一个思路转换。
具体以页面跳转为例子,页面跳转是靠链接 实现,链接是页面经常使用的元素。
Struts提供的html:link在频繁使用就特别不方便,尤其在传递多个参数时:其中html:link的page值,是跳转对方页面或 Action的path,这个path一般需要到struts-config.xml查找Action的相应path,一旦配置文件path值修改,涉及到这个所有相关页面都要修改。
JSF将链接概念划分两个方面:导航性质和事件激活,在导航方面还是需要到配置faces-config查询Navigation的from-outcome的值。
由于Tapestry没有标签库概念,只有组件或页面两个概念,因此,链接跳转目标要么是组件,要么是页面,简洁简单,它没有多余的path概念,就是组件名,也就是对象名称,组件名称和path名称合二为一。
总结
JSF在很大程度上类似Struts,而不是类似Tapestry,可以说是一种Struts 2.0,都是采取标签库+组件的形式,只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制;JSF在事件粒度上要细腻,不象 Struts那样,一个表单一个事件,JSF可以细化到表单中的每个字段上。
JSF只有在组件和事件机制这个概念上类似Tapestry,但是不似Tapestry那样是一个完全组件的框架,所以,如果你做一个对页面要求灵活度相当高的系统,选用Tapestry是***考虑。
Struts/JSF则适合在一般的数据页面录入的系统中,对于Struts和JSF的选用,我目前个人观点是:如果你是一个新的系统,可以直接从JSF开始;如果你已经使用Struts,不必转换,如果需要切换,可以将JSF和Tapestry一起考虑。
另外,JSF/Tapestry不只是支持Html,也支持多种客户端语言如WML或XUI等。
这三者之间关系:如果说Struts是左派;那Tapestry则是右派;而JSF则是中间派,中庸主义是SUN联盟的一贯策略。
当然,你也可以发表你在实践中这三者任何一个的使用感受,以使得后来者有一个比较。
分享标题:表现层框架Struts/Tapestry/JSF比较
网站链接:http://www.shufengxianlan.com/qtweb/news48/106198.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联