可以使用多个jsp定制标签在JSP中达到接近servelt的处理效果

原文 

jsp(SUN企业级应用的首选)可以令菜鸟直接写简单的网页程序（网友言），而servlet却有jsp(SUN企业级应用的首选)所不及的集成程度和易维护性。两者在JAVA/BS系统中无法简单取代，但同时并存却令开发者陷入近两年来最常见的陷阱中：必须在一个即使是相对简单的项目中维持多套程序模式的方案，显然，这是高成本的。本文考虑并初步实验了使用标签组件连续完成类似servlet的处理效果，从而达到鱼和熊掌兼得的目的，看来有一定的效果。

    在完全使用servlet的环境中，可以使用servlet的继承获得上级servlet的设定属性；还可以使用servlet-chains达到分类处理的目的，整个WEB程序与实际应用系统非常相似，高效而简洁；在servlet-jsp(SUN企业级应用的首选)的环境中servlet起到集中处理请求的作用，而jsp(SUN企业级应用的首选)负责显示各种形式采摘的数据。后者最麻烦的就是在servlet/jsp(SUN企业级应用的首选)中的数径和变量处理方式不一致，平添大量的原始的工作量。strutsr actionmapping一定程度上解决这个问题，不过解决得不算太彻底。因此在大型的java BS应用中采用servlet/jsp(SUN企业级应用的首选)形式所带来的方便，一定程度上将会被这种变量的不一致性所抵消，毕竟，维持两种处理方案本身就是高成本的。

    因为这个原因，过去本人干脆完全采用servlet形式，而通过另外写程序解释由网页人员编写的嵌套式的html来达到与jsp(SUN企业级应用的首选)类似的目的。这套方案在三四年前是有效的，但在今天由于SUN选择了jsp(SUN企业级应用的首选)作为发展的主体，包括JTL，TAG技术，甚至于jsdk1。5中的cacheResutlSet都是为了这种（我认为是落后的）jsp(SUN企业级应用的首选)随机编码而开发，因此，独自坚持走servlet道路是不明智的,(参看本人《选择jsp(SUN企业级应用的首选)作为BS发展方向很可能是致命的战略失误》一文)；但是，同样的疑问并不会因为SUN选择了jsp(SUN企业级应用的首选)而消失：如果完全采用jsp(SUN企业级应用的首选)，那么在数据提交处理上还是必须使用SERVLET以简化处理逻辑，但同时也必须承受上述的负面作用。

    作为SUN赞助支持的JAVA/BS主体项目方案之一的struts框架充分体现了这一矛盾带来的困惑和折衷：struts- action/actionmapping本身就是为了达到克服上述的jsp(SUN企业级应用的首选)不足，希望鱼和熊掌兼得，通过ActionServlet令使用者减少 servelt程序的编写量；不过，在不能完全解决问题的同时，也令开发者为了这不是主体需求的需求，而必须多采用一个框架；一定程度上实际上是得不尝失。

    如果上述逻辑成立，那么如同几年前本人完全选择servlet一样，既然选择了jsp(SUN企业级应用的首选)作为主体方案，那么就应该考虑完全抛弃servelt，以便以一套方案处理项目，避免维护两套系统带来的附加性成本。但是如同所有人在若干年前指出的一样，jsp(SUN企业级应用的首选)缺乏有效的代码管理手段；也不便于形成象servlet那样的基本框架体系，这样它与简单的网页程序如ASP/PHP没有什么不一样。引入javabean(组件，不是简单的数据对象化载体），可以一定程度上改善这种处境，但javabean缺乏统一的调用规范，却令这样的jsp(SUN企业级应用的首选)