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