canonical

一个技术的成功，在于最终占据了某个概念。当我们应用到此概念的时候，首先想到的就是这个技术实现，久而久之，形成一个自我证明的过程。而有些技术却是在 其位无能谋其政，实在是让人不得不为它扼腕叹息呀。jsp tag正是这样一种技术。有些人认为jsp tag只是jsp的一种扩展，只是一种syntax suger, 这正反映了此技术所面临的一种困境。这里指出一些jsp tag的设计缺陷，并无贬低这种技术的意图，只是希望抛砖引玉，引发大家对这种技术改进的探讨。
引用:
jsp tag是服务器端的扩展标签机制，它是一系列java服务器端技术的基础。但其设计之初的几个重大缺陷已经使得这种技术不堪重负。  

对比dotNet平台我们可以知道，需要一种后台标签机制，jsp tag是唯一的标准（JSF等机制都依赖于此)，可它的设计给所有希望基于它开发的开发人员造成了巨大的困扰。实际上我对这个技术感到很失望，当然我们提 出了相应的替代方案。在我们的开发框架中使用的是重新设计的一套与网络无关的xml动态标签机制。我的观点是基于jsp tag技术，无法开发出与dotNet的便捷程度相当的服务端技术，所以这是它作为标准的罪过。jsp tag不应该是jsp的补充，它搭上了xml这条大船，应该去走自己的路，而不应该成为应用上的鸡肋。
引用:
1. jsp tag与jsp 模型紧密绑定，使得业务逻辑很难抽象到tag中。而且脱离了jsp环境，在jsp tag上的技术投资将一无是处。  

这里说业务逻辑可能是有些不妥，容易引起误解。因为我的工作做在中间件层，所以我的原意是基于jsp tag开发一系列的扩展技术，比如缓存等。我们的xml标签技术是与jsp模型无关的，在前台用于界面渲染，在后台用于工作流描述。而且很方便的就可以与 其它xml技术结合，比如集成ant。

引用:
2. jsp tag的编码逻辑非常繁琐, 特别是写loop和容器类标签的时候。在2.0之前不支持从tag本身产生tag更是应用上的主要障碍。  

这绝对是个重大问题，试问多少人自己去开发jsp tag呢，多半是用用别人的成品。编制困难其实就是否定了界面元素的重用。很多人推崇Tapestry, 其实如果jsp tag技术方便一点，何必建立一个完全不同的模型呢。

引用:
3. 使用将xml标签的属性直接映射到对象属性的方法造成tag对象是有状态的，不得不通过丑陋的pool机制来解决性能问题。
而且性能问题直接限制了大量小标签的使用。  

这是一个现实的困难，一个系统设计师必须考虑。

引用:
4. jsp tag是一种完全动态化的设计，大量可以在编译期进行的优化都无法进行，基本上所有的运算都是在运行期发生，限制了性能的提高。  

我们的xml标签技术是先编译再运行的，加上无状态设计，在性能上可以得到控制。我的朋友hotman_x是个C++和js高手，在他的强烈要求下，我们的xml标签还增加了一个多次编译的机制。

引用:

5. 虽然最近的版本已经支持xml格式，但对于xslt等的集成很不到位，例如现在无法使用xslt对jsp文件进行界面布局。

最简单的
<web:template src="test.tpl" xslt="layout.xslt" />
<web:mytag xdecorator="face.xslt">
...
</web:mytag>

引用:
6. jsp tag要求使用自定义标签名，而无法对已经存在的html标签进行enhance, 造成无法方便的在可视化编辑器中进行编辑。  

Tapestry就认为它比较好。我们的xml标签机制也支持属性扩展。

引用:
7. EL表达式竟然不支持调用对象函数

很多人因此觉得OGNL比较好。我们的机制中是对EL做了一定的增强。我不喜欢OGNL, 过于复杂了。