Web显示层技术评估 -- 4.评估指标

评估指标

下面列出一系列比较详细的、能够落到实处的、能够客观量化的、可操作的评估硬指标。

排名不分先后。大家可以参考各自关心的选项。

虽然下面主要针对的都是Java Web 显示技术,但这些指标同样适用于其他语言的Web显示技术。

评分采取10分作为满分。

(1) Host Language Consistency宿主语言一致性

Server Side Template ScriptServer Host Language是同一种语言。这应该是专门针对JSP的优势来说了。JSP能够获得10分。

另外,XSL也是。XSL本是也是XML格式。也能够获得10分。

其他的Template Script,如taglib,tapestry只能获得0分。

freemarker, velocity由于具有一定的动态解释的方便特性,可以获得2分。

至于在Java Code里面操作Template或者提供匹配数据的那些技术,由于Template中不存在Script Logic,能够获得5分。

大家可能不太注意这个特性。但是这个特性还是有一些意义的。其他的如ASP.net,还有动态语言,Ruby, Python, PHP, Perl等,都是Template Script和宿主语言一致。

这能够一定程度上降低学习成本。尤其是宿主语言比较适合作为Script的情况下。

 

(2)Template Purity 模板纯净度

这主要是指Template里面没有Script Logic代码污染。

这方面,所有的Scripted Template技术都只能获得0分。

XMLC能够获得10分,只利用HTML本身的Attribute,没有增加任何自定义DOM Attribute

Wicket, DOMPlus能够获得9分,它们增加了一部分自定义DOM Attribute

JDynamiTe, Fastm能够获得7分,它们采用了XML Comment作为自定义结构标签。

Rife也能够获得3 -- 7分,具体看它采用什么标签格式。

(3)Template Tidiness 模板整洁度

主要是指Template的格式是否整齐规范。Taglib, XSL无疑是胜利者,本身就是XML格式,通用的XML Parser就可以解析它们,比较容易在IDE Plugin中处理。

XMLC, Taglib, XSL能够获得10分。

Tapestry, Wicket, DOMPlus 也能够获得10分,同样是XML格式。

JDynamiTe, Fastm, Rife能够获得5分。

JSP, Velocity, Freemarker只能获得0分。

(4) Replacement Flexibility 替换灵活度

主要是指能否自由替换Template里面的任何一块文本。不用考虑DOM Node

JSP, Freemarker, Velocity, Rife, JDynamicTe, Fastm无疑是胜利者,毫无限制,能够获得10分。

Taglib, XSL, Tapestry, Wicket, XMLC, DOMPlus都或多或少受到DOM Node的限制(解析的最小单位是XML Node),能够获得6分。

(5)WYIWYG 所见即所得

Template能够在Browser里面直接大致正确显示,设计人员友好。

XMLC, DOMPlus得分10

Wicket得分9

JDynamiTe, Fastm, (Rife根据情况) 得分8

Tapestry得分7HTML毕竟夹杂了Logic Tag

JSP, Freemarker, Velocity, Taglib, XSL得分0

 

Freemarker, Velocity属于按行解析,有可能采取如下手段,把语句包含在XML Comment里面,进行显示友好的处理。这种情况下得分5

<!--

#if ….

-->

 

由于TaglibXML规范格式,使得某些IDE PluginDreamWeaver Plugin能够显示HTML Display Taglib。如果是对于此类Plugin来说,Taglib的所见即所得分数可以是0-- 5分。类似于Tapestry,仍然是Logic Tag影响了最终得分。

(6)Action Code Purity 用户代码纯净度

主要是指用户提供显示数据的后台Java代码的纯净度,是否免除了HTML,或者Template操作的污染。

ServletHTML污染现象就非常严重。代码里面夹杂了大量的HTML Text。分数自然是0

JSP, Freemarker, Velocity都能够获得10分。用户后台代码十分纯净,不需要引入具体框架的代码。任何一份Action Code,完全不用知道自己使用的是什么Template,这三种Scripted Template都能够随意替换。能够获得10分。pojo

Taglib根据各种具体情况,能够最高获得8分。

Fastm, DOMPlus需要根据一定的约定,产生POJO数据。用户Action Code同样不需要引入具体的框架代码,产生的这些数据同样可以很容易地被其他Template,比如JSP, Freemarker, Velocity使用,能够某种程度上替换Template。能够获得6分。

Tapestry需要在每份用户Action Code里面引入Template框架的Package。只能获得4分。

Wicket不仅需要在每份用户Action Code里面引入框架的Package,还需要引入框架特殊的View Data Model数据类型,并且提供特殊类型的数据。只能获得2分。

XMLC, Rife, JDynamiTe不仅需要在每份用户Action Code里面引入框架的Package,而且需要大量的Template操作。只能获得0分。

 

(这项特性的比较,对于TapestryWicket来说是不公平的。因为它们的框架就包括了Template本身。Action里面引入框架Package是很正常的。而且这些框架同样可以外接其余的Template,只是原来的编程模型,需要做一些更改。这里只是对于单项比较就事论事。)

(7) Infrastructure Code Purity 基架代码纯净度

这里是指框架的内部实现代码里面是否夹杂了HTML Text污染。这也意味着如果用户需要扩展页面UI组件,是否也需要在代码里面夹杂HTML Text

HTML Taglib, Wicket, Tapestry的框架实现代码里面包含了很多HTML Text输出语句。用户需要自定义扩展页面UI组件,也需要在代码里面夹杂HTML Text。所以,得分只能是0

JSP, Freemarker, Velocity, XMLC, XSL, Rife, JDynamiTe, Fastm, DOMPlus得分都是10

(8)动态Include

即运行的时候,动态选择Include另外的Template文件。

JSP文件里面的 @ include 属于静态Copy And Paste技术。

Jsp:include命令是动态Include,相当于

request.getRequestDispatcher(…).include(request, response);

 

Velocity, Freemarker#Parse指令应该也是动态解释执行的。也可以算是动态Include

至于XMLC, Rife, JDynamiTe这类技术能够随意操作Template Node,动态Include也是小菜一碟。

Fastm, DOMPLus同样提供了操作Template Node的能力,而且为了避免这类Template Manipulation代码污染,还提供了类似于XSLNode Interceptor的机制实现动态Include

XSL Apply Imports Call Template能够动态引入并使用其他的XSL

 

所以,JSP, Freemarker, XMLC, Rife, JDynamiTe, Fastm, DOMPlus, XSL的动态Include方面的分数都是10

其余的,Taglib, Wicket, Tapestry得分为0

(9)Recursive Display of Tree Data树型数据的递归显示

递归显示一个任意深度的树型数据,这是一个动态Include基础上的更高级的需求。可以说,不支持动态Include,就不支持递归显示。

递归,XSL无疑是天生赢家。XSLPattern Match语法可以说就是为递归编写的。

其余的语法都是Imperative Programming。递归的前提是必须能够定义一个方法,自己直接或者转弯抹角的能够调用到自己。

对于JSP, Velocity, Freemarker这类没头没尾的Script来说,属于强人所难。

Tapestry, Taglib, Wicket比较牛,专门提供了Tree Model

XMLC, Rife, JDynamiTe这些Template Manipulator高兴了,可以在Java代码里面任意根据数据任意操作Template Node

Fastm, DOMPlus不仅可以在Java代码里面任意操作,而且提供了类似于XSL Pattern MatchNode Interceptor功能,不需要写Template Node操作代码,就可以实现递归。而且可以实现Data Iterator + Template Iterator的匹配序列。

 

递归方面,得分如下。

XSL, XMLC, Rife, JDynamiTe, Fastm, DOMPlus得分10

Tapestry, Taglib, Wicket能够显示特定的Tree Model。得分4

其余的,得分0。只能通过Java代码里面夹杂一堆的HTML Text,然后整体输出给Scripted Template来实现。

(10) Space Efficiency空间效率

基于Template Manipulation的技术都有空间效率问题。用户同时访问同一个Page的时候,内存中存在多个副本。XMLC的问题可能最重。因为XML DOM结构很重。

JDynamicTe, Rife直接在一个Template Node上操作,如果有多个用户同时访问同一个Page。那么同一份Template Node就会在内存中Duplicate多份。

 

空间效率方面得分情况

XMLC得分0JDynamicTe, Rife得分3。如果静态文本节点作了优化,分数可能更高。

Taglib由于编译的结果非常臃肿,Tag之间的信息交流非常困难。分数为6

DOMPlus一份DOM产生多份SAX Event,没有严重的多副本问题,但是DOM结构本身比较大,所以得分为6

其余的技术,内存里的静态文本都只保存一份,都没有严重的空间效率问题,得分都是10

(11) Mapping Explicitness 映射关系明显度

什么数据应该显示在什么位置,一目了然。这种特性。

JSP, Velocity, Freemarker直接在Template里面把数据取出来显示,一目了然,清清楚楚,得分都是10

Wicket的强制View Model 类型这里帮了大忙,无时无刻不提醒用户Model View (Template)之间的映射关系。得分8

XMLC直接操作HTML Node By ID, or By Generated Method, 得分为7

比起,JSP等来说,Taglib的映射关系就隔了一层。尤其是当Tag之间存在层次关系的时候,比如,Form Tag下面的Input TagSelect Tag下面的Option TagTaglib的分数只有6

XSLXPath Pattern Match也是要稍微转个弯,类似于AOP Interceptor的思路。得分为5

Tapestry的配置如此复杂,得分只有4

Rife, JDynamicTe直接操作Template Node,而且是自定义层次的Template Node,用户编写Action Code的时候,必须随时查看Template里面的那些自定义标签之间的层次关系,并完全理解,了然于胸,才可能编写正确的代码。这方面的成本大大提高。分数只有3

Fastm, DOMPlus的问题类似,也是自定义层次的Template Node,需要随时查看Template里面的那些自定义标签(或者DOM Attribute)之间的层次关系。分数只有3

 (12) Display Logic Reusability 显示逻辑重用度

嵌在Template里面的Server Side Script代码,不具有任何可重用性。除了整个Include,你无法在另外的地方调用Template里面的某一段代码。

JSP, Velocity, Freemarker, Logic Taglib, Tapestry Logic TagXSL的逻辑可重用度分数都是0。当页面设计人员更改了具体页面布局元素(HTML Tag)的时候,原来的Template里面的Script全部作废,需要重新填充到新的HTML里面。

Template ManipulationModel Match技术的显示逻辑都存在后台的Java代码里面,自然是可以重用的。方法调用,类继承,包含,怎么都行。

 

WicketView Model都是绑定到具体的HTML UI Tag上,比如,List, Table等。当这些Tag变化较大的时候,原有的代码都需要改变。某些HTML Display Taglib也是如此。重用度分数为4

当结构层次没有变化,只是具体的HTML Tag变化的时候,XMLC的原有DOM处理代码几乎不需要变动。在处理循环的时候,代码需要Create Specific HTML DOM Node,然后添加到某个DOM Node上面。而且代码可能大量使用自动产生的代码的方法。这影响了它的得分,分数为4

当结构层次没有变化,只是具体的HTML布局元素发生了变化,那么,Rife, JDynamiTe,的代码都不需要变化。但是,它们的代码侵入性非常强,比XMLC还要强(如果XMLC采用标准的HTML DOM操作方法)。权衡考虑,Rife, JDynamiTe的重用度分数是5

当结构层次没有变化,只是具体的HTML布局元素发生了变化,Fastm, DOMPlus的代码也不需要变化。而且,Fastm, DOMPlus没有代码侵入性,产生的Data Model就是POJO,可以用在JSP, Velocity, FreemarkerTaglib里面。所以,重用度分数为8

 
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
《开源软件成熟度评估及选型指南》内容主要来自近几年我们对开源软件评估与应用选型的研究成果,以及对优秀的开源软件的筛选整理。内容主要面向那些希望将开源软件部署在其应用环境中,或利用开源软件进行二次开发的中小企业或开源爱好者。《开源软件成熟度评估及选型指南》对于那些利用开源软件的网络社区建设者也有一定的参考价值。 全书内容共分为四部分:第一部分主要讲解开源软件的相关概念,开源运动在国际和国内发展的历史,及开源软件应用普及中遇到的问题;第二部分主要讲解开源软件选型中成熟度评估模型在国际、国内发展的情况,并依据近几年我们在相关领域的研究、探索,结合国内外经验,提出一个成熟度评估模型;第三部分着重讲解在开源软件选型中非常重要的环节——开源软件许可,通过问答的方式向大家讲解开源许可相关的知识产权问题对开源软件选型的影响,并对开源许可中最重要的GPL协议进行了分析;第四部分向大家推荐一系列互联网开发、应用相关的开源软件,也作为我们对开源软件选型方法的实践。此外,在附录中给出了一个软件评估规范的参考范本和一些开源软件相关知识点的详细介绍。 《开源软件成熟度评估及选型指南》的一些内容来自相关项目或软件的官方信息;同时,《开源软件成熟度评估及选型指南》的内容也获得了开源中国社区和中日韩东北亚开源合作项目的大力协助,在此对他们深表感谢。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值