标签库，几乎是每个MVC框架的重要组成部分。从Struts1开始，到Webwork2，SpringMVC，都有自己的定义的一套标签库。所以，一度标签库的使用，会成为一个框架初学者判定一个Web框架好坏的重要标准之一。我也曾经见到过许多Web开发人员，长期地存在着一定的误解：只要学好标签库，能够将标签库熟记于心，那么这个框架我就算掌握了七八成。

标签库，只是框架的一部分，为了解决页面显示数据、封装简单页面逻辑而产生的类HTML标记的组件。

所以千万不要把标签的作用神化，也不要认为学习标签是学习Web框架的重中之重，因为他们只是框架中的小小一部分。

在JSP诞生之初，JSP提供了在HTML代码中嵌入Java代码的特性。这种特性使得我们可以比较容易的利用Java这种强类型语言的优势，完成许多复杂的业务逻辑。

不过随着时间的推移，我们发现在HTML代码中嵌入过多的Java代码，非常不利于JSP的维护和扩展。对于动辄上千行的JSP代码，很多时候，程序员基本丧失了对JSP的维护能力。基于上述的这个问题，我们尝试使用一种新的技术，来解决上面这些问题。这也就是标签产生的初衷：

1. 尽量避免在JSP页面中使用Java代码，而改用类似HTML的标签的形式来表达页面逻辑，让逻辑与显示分离，提高JSP的可维护性

2. 由于HTML自身的标签的表达能力不足，通过使用JSP Tag，可以对HTML语义进行扩展，从而完成许多HTML自身标签无法完成的工作

有关标签，争论一直存在着。早在2004年的时候，robbin同学以一文《炮打Taglib，我的一张大字报！》引起了许多人对Taglib的讨论。当时，robbin同学的观点大概是这样的：



不知道时隔快5年，robbin的观点是否有所变化。在这5年中，JSP的表示层方案实际上并没有发生很大的变化。Taglib也并没有消亡，AJAX技术更加蓬勃的发展，模板技术已经被视为成熟并可供使用的重要表示层技术。

标签，到底是解药还是毒药？它到底能不能为View层开发带来便捷？这个问题，我们需要更加辩证的来看待。我们首先将所有有关标签的观点总结成正反两派：

正方

1. 标签产生的初衷没有错，它的存在，能够简化JSP开发的难度，并对HTML的许多标签进行功能扩展

2. 标签从效果上的确在一定程度上解决了在JSP页面中，避免使用Java代码的情况

3. 由于Java的语法与表现能力上的优势，使用Taglib能够极大程度的封装成块的HTML代码，从而形成一套完整的页面组件，能够极大的简化页面开发

反方

1. 标签只是为了尝试避免在JSP页面中使用Java代码，实际上，这种情况很难避免。有时候，为了达到这个目的，反而带来了更多的代码和沉重的维护成本。一个很简单的理由，编写一个Tag，至少需要一个tld文件定义、一个Java的实现类、JSP中去声明tld并编写Tag。显然，对于许多情况而言，这样所带来的代码量，反而超过了在页面上直接使用Java代码

2. 不仅如此，标签的存在为广大程序员带来了无穷无尽的学习成本。因为根据使用的框架的不同，会带来不同的标签库。再加上许多公司在标签库为基础的页面组件方面的积累，公司内部就有一套标签库，于是学习这些标签的语法已经成为了程序员的沉重负担

3. 对于以标签库为基础的页面组件，在面对经常变化的页面逻辑时，显得无能为力。因为它的维护成本极高，当逻辑变化频繁时，这些页面组件的表现能力，还不如直接通过JavaScript操作HTML DOM来的方便

为此，正反双方也是各执一词，各有道理。在这点上，JSF是强烈站在正方观点上的一个Web层框架，它试图通过IDE的帮助，来解决反方所说的维护成本和学习成本的问题。而许多其他的Web框架，则相对保持中立，对于标签库，采取“不抛弃，不放弃”的原则。

如果我们比较理性的来看待这个问题，也只能说，这是一个编程方面的哲学问题。每个人应该根据自己对待代码的哲学理解进行答案选择。千万不要因此而引起框架之争。

正反双反的激烈辩论，也推动了View层的发展，因为正反双方都在寻求对方的破绽，从而找出解决方案反驳。

从正方来讲，大约做出了以下的一些进展：

1. 制定标准标签库JSTL，试图统一绝大多数的标签

2. 借助IDE的帮助，打造更多更丰富的Web层组件，并加强AJAX等功能

3. 将成熟的JavaScript UI框架，改造成Taglib的形式

4. 随着EL的逐步推广，在JSP中使用EL也越来越能够被大家接受

而反方，则大刀阔斧的对View层的表现形式做出了改革，并且被越来越多的程序员所接收：

1. 放弃Taglib，推崇模板技术

2. 不使用Taglib来构造页面组件，而更多的采用JavaScript技术来丰富页面展示

3. 直接放弃使用HTML为模式的页面展现方式，改用Flex等Flash表现方案

从实际效果上来看，反方的方案更加激进，有的干脆直接抛弃了HTML，采取其他的表现形式。使用JavaScript进行页面渲染的代表应该是Ext，你几乎无法看到HTML代码了。而模板技术作为一个新兴的技术，也得到了越来越多的程序员的青睐。这几年以来，富客户端的发展如火如荼，不知道是不是也能够成为反方强有利的论据和武器。

而正方，他们所能做的相对比较局限，支持Taglib，无疑就是把Taglib进行扩充，这一点似乎基本上以JSF为首在推基于Taglib的组件，效果如何，自有公论，在这里我也不做过多的评论了。

在深入探讨每个框架的标签之前，我们先来为标签分一下类，我们分类的标准，主要是根据标签的作用。

逻辑控制类

以JSTL为例，JSTL大概提供了以下一些标签，用于逻辑控制的标签：

• c:if     ———— 分支判断
• c:forEach      ———— 循环
• c:choose / c:when / c:otherwise     ———— 分支判断
• c:catch      ———— 异常处理

逻辑控制类的标签实际上每个框架基本上都有，因为逻辑控制是组成程序的基本要素，可以说，逻辑控制类的标签在JSP中，也是必不可少的。只是不同的Web框架对逻辑控制类的标签的定义稍有不同，其本质还是一样的。

数据输出类

同样以JSTL为例，JSTL大概提供了以下几个用于数据输出的标签：

• c:out     ———— 输出表达式的值
• c:url     ———— 输出格式化url
• c:set     ———— 设置表达式的值
• c:param     ———— 设置参数
• fmt:message   ———— 输出资源文件中的值
• fmt:formatDate    ———— 格式化输出日期
• fmt:formatNumber    ———— 格式化输出日期

数据输出类的标签每个框架也都有。比如Struts1中，著名的<bean:property>标签、webwork中，著名的<ww:property>标签等等。这些标签对于JSP页面来说，也是必不可少的。因为JSP的基本作用就是展现数据，这些标签正是为了展现数据而提供的。

页面组件类

页面组件类的Taglib就更多了，以Struts2为例，Struts2提供了无数UI Tag，具体可以参考：

http://struts.apache.org/2.0.14/docs/tag-reference.html

这些UI Tag实际上是对HTML标签的扩展和扩充，添加框架本身特有的特性。所以，这类标签，如果使用得当，将为开发带来极大的便捷。如果这类标签使用不当，则会带来很大的学习成本和维护成本。事实上，这些标签对于JSP来说，并不是必须的，只是对UI的开发起到辅助的作用。

小结

除了上述这3类Taglib以外，我们还会有很多综合类的Taglib，这些Taglib往往都是为了解决特定的页面逻辑或者页面展示而做出的自定义的标签。

在我们仔细分析了标签的分类之后，我们能够发现，前两类的标签实际上对于一个框架和JSP开发而言，是具备价值的，也是必不可缺的元素，而对于后一类的标签，我们应该谨慎对待。事实上，这些标签往往可以通过其他的方式代替。我想许多针对标签的反对的声音，绝大多数也来自于最自定义的页面组件标签的抨击。如果你在UI的标签上，表现出了学习上的不适应性，那么你完全可以思考着采取其他的方案来代替，而不是在一条死胡同里面。

首先，我并不想在这里举出非常具体的例子来说明每一个标签中每个属性的用法，因为这些东西其实大家都可以通过API手册获得，我希望列出一些在设计思想上有所差异的标签种类，并细细品味一下这些Web层标签的设计初衷和设计思想。

Struts / Webwork

Struts和Webwork的标签是最传统的标签。按照我上面所说的分类，Struts和Webwork基本上在每个分类上都有相应的标签实现。不仅如此，Struts2还在页面组件化上下了点功夫，将许多页面组件定义成了标签的实现。我个人对Struts2的这种做法持保留态度，因为Taglib毕竟在扩展性和实用性上不如直接使用JavaScript等成熟的框架来的方便。

不过Struts和Webwork的标签相对来说还是比较好用的，因为它的许多内部实现与HTML自身的标签属性非常一致，降低了程序员学习的成本。

JSTL

JSTL也是时下非常流行的一个标签库。由于JSTL是Sun力推的标准化标签库，所以其刚刚诞生，就奠定了其试图统一标签世界的想法。不过实际上，从标签的分类中，我们也可以看到，JSTL主要实现的内容，是第一类和第二类的标签，而没有第三类标签。按照它的想法，第三类的标签应该由用户自己去实现，或者采用其他的替代方案。

JSTL的好处是毋庸置疑的。它会依次从page、request、session、application作用域中查找表达式的值，使得它能够兼容一切Web框架。因为所有的Web框架基本上还是围绕着这些Servlet对象来打交道。另外一方面，JSTL的标签数量比较少，学习成本很低，所以很多程序员都喜欢学习它。

Tapestry

Tapestry的思路与其他Web框架实现标签的思路全都不同。Tapestry提倡所有的页面都HTML化，不应引入额外的HTML标签，如果你需要实现页面逻辑，应该以组件的形式完成，而这些组件的页面调用方式，是在HTML标签中加入一些自定义的属性。

<table>  
    <tr>  
         <td>User Name</td>  
         <td>Action</td>  
    </tr>  
    <tr jwcid="@Foreach" source="ognl:users" element="tr" value="ognl:user">  
         <td><span jwcid="@Insert" value="ognl:user.name">Quake Wang</span></td>  
         <td><a href="#" jwcid="@ActionLink" listener="ognl:listeners.deleteUser">Delete</a> <a href="#" jwcid="@ActionLink" listener="ognl:listeners.updateUser">Update</a></td>  
    </tr>  
</table>

 

这里我引用了Quake Wang同学曾经使用过的例子。虽然这个代码还是Tapestry3时代的代码，但是我们可以从其中看到许多Tapestry在标签设计上的独到之处。它没有额外的标签定义，但是有额外的标签内属性定义，并通过框架，将这些定义与后台组件联系在一起。

这或许也就是许多Tapestry程序员对这个Web框架钟爱的原因，由于没有额外的JSP标签定义，那么页面展示使用HTML也就够了。所以，所有的程序员都号称Tapestry是对美工最友好的Web框架。

我个人对待上述观点是无法认同的，理由非常简单，额外定义标签，与标签中额外定义属性，从本质上来说，区别不是很大。从学习成本而言，也陡然增加了程序员学习组件的成本。对于美工呢？他们能忽略这些额外的标签嘛？理论上，可以，不过如果大家试试看一个比较复杂的带有多处分支判断的页面，美工MM同样会非常痛苦。

总体来说，Tapestry的标签具有它的特色，从设计上也有巧思之处。如果我们将这种思想移植到普通的JSP里面来，其实我们完全也可以使用类似的方式，在HTML标签中定义额外的属性，并使用JavaScript来控制这些属性的行为，同样可以形成页面组件。