JSTL标签是SUN带头与apache社区合作的产品，可惜从一出现就已经是一个过时的技术。SUN的软件架构师似乎缺乏从顾客角度考虑技术取向的能力，与微软相比差之千里。就标签技术而言，它的目的是令菜鸟中的菜鸟变得可以写JSP，还是令一般程序员写JSP显得更方便，更好管理？显然，SUN的那位笨蛋架构师没有想明白这个道理（越是看得多它的文档介始，越是觉得那个家伙是个大笨蛋)，把SUN数千名天才工程师的才智白白浪费了。
所有人都已经知道，JSP出现的目的就是为了让程序员更方便地写简单的servlet,复杂的多功能的servlet是不容易用JSP实现的。而JSP希望让菜鸟写java动态页面的目的并没有达到，这条，还不如ASP/PHP。在JSP中散布底层业务逻辑既不便于对象组织，也不但于代码管理，非常低效。这是发展出javaBean和标签技术的原因；而JSTL呢，它的基本客户逻辑竟然是为了帮助使用者更方便地把底层代码散布在JSP上！？包括数据库连接？！所以这东西是一个新的技术实现落后目标的产品，面对市场需求整整慢了一拍。
唯一有点价值的是它的循环逻辑，这条还是很有用的。只不过能够实现的不止它一个，struts.logic标签就是很好用的一种，而且不用指向http:/sun.xxxx/core什么的，事实上JSTL能够提供的struts:logic也能够提供。实际上struts几个标签库中也就logi,有点价值，bean也可以，其他的html是纯粹和FormBean为核心的MVC设想框架提供的。即使这样，就实用性而言，strutslib仍比sun实用得多。
struts标签库不能很好地面向数据对象，这是它的不足，hanva标签就是为了补充这个不足。结合struts的logic库，使用hanva标签可以达到在jsp中声明和接收变量，可以实现多种逻辑，可以直接从底层获得持久性非持外性的数据对象，处理并输出——一个程序大致也就只有这些东西做的。特殊的东西再特殊处理，直接完全使用标签调用下层服务daemon程序完成绝大部分功能，已经可以做到了。
下面的论坛示例删除程序是这样的一个功能，可以处理任何的实现了hanvaDAO接口规范的表数据的删除，包括对其相关数据记录的同步处理。它接收一个对象类型(ent)，及ID，判断这个对象（行记录）是否存在，然后判断它的sourceid和id是否一致（是主贴还是跟贴），如果是主贴，就把它的从贴一起删除，否则就只删除当前贴，然后返回原来调用的一页，如果出错，就转向到errors.jsp页，显示出错信息。
<entity:present ent="${param.ent}" oid="${param.oid}" id="thent" nexto="${header.referer}">
<%--如果记录存在就继承内嵌逻辑，把该记录定为ident名--%>
<%--判断sourcid与id是否一致--%>
<logic:equal name="thent" value="${thent.sourceid}" property="id">
<%--取所有主从贴，集合定名为theobjs--%>
<entity:entities ent="${param.ent}" id="theobjs" qstr="sourceid=${sourceid}">
<%--迭代集合内容，单个取名为theobj--%>
<logic:iterate id="theobj" name="theobjs">
<%--删除该对象--%>
<cmd:delete ent="${param.ent}" target="${theobj}"/>
</logic:iterate>
</entity:entities>
</logic:equal>
<logic:notEqual name="thent" value="${thent.sourceid}" property="id">
<%--单个从贴，清除该对象--%>
<cmd:delete ent="${param.ent}" target="${thent}"/>
</logic:notEqual>
</entity:present>
标签结束，根据nexto转向到调用者，这样段小代码实际上就扮演了一个MVC中的c角色。如果需要输出断点，可以调用hanva:log 把实时内容输出到log日志中。一个比较复杂的功能就此完成了。全程实际上只是进行了一次或两次数据库的访问，如果是多个从贴，需要获得它的串，这是可能的第二次。注意<entity:entities>标签，它输入一个条件，也可以输入fields选项，得到一个ArrayList串（没有同步要求就不用Vector），如果不是为了翻页，它可以代替hanva:list，使用上也更方便，没有需要先设定一个dao.list对象。
我认为这才是标签技术的真正用法：帮助程序员在界面清晰明确地调用后台的处理程序，方便面向对象的业务逻辑的建立，方便隐藏非表达层的逻辑;而不是变成把页面搞得更复杂，堆上更多难懂代码的又一套新方法。
相对而言，tags文件标签技术显得更现实一点。如同jsp是方便菜鸟（仍是程序员）写简单的servlet一样，tags标签文件是方便看到Class就发抖的菜鸟象写jspjavalet一样写标签；显然，是最简单的SimpleTagSupport的变种，只有它才有一个体内容。也同样，充分利用Class类结构的编码技术在这里没有办法实现。
JSP开发社团看来热衷于在局部别具一格地提供一些局部方便性措施，却常常忽略了客户更大的一个要求：在项目开发中尽可能采用单一的标准的范式完成所有程序。多使用一种小技术模式在局部方便了，全局来说却是多管理一种一种技术，或者说程序员要多学一种只在局部有效的技术。这个逻辑错误从J2EE开始就伴随着SUNJAVA的技术发展，看来是它的不治之症。在笔者看来，与其多搞小动作，不如在核心一钻到底，而小范围内的方便措施，还是有有能力的客户去实现为佳。拙劣地模仿微软去拍落后（也是非主流的客户）的马屁，将是SUN公司技术上最终失败的原因。