网络开发框架Stripes要怎么做呢？
框架的学习难度都很大，尤其是它们的标签库与配置文件，很让人头痛。
发现了一个网络框架Stripes，立刻就引起了本人极大的兴趣。其实该框架在2005年就发布了，不久前发布了1。5版。让我感到意外的是国内业界似乎对其很少提及。 考试,大提示本文不嫌粗陋，对Stripes略加介绍，以期抛砖引玉。
软件的展示层（presentation layer）是最麻烦的。以网络应用为例，软件的最终输出，须以符合html的要求。此外，尚需对html元素进行修饰和定位，这就用到了CSS技术。 如果进一步，可能尚需dhtml和Ajax。也就是说，还需要应用JavaScript技术。
而网络框架的功能主要有两...全部
框架的学习难度都很大，尤其是它们的标签库与配置文件，很让人头痛。
发现了一个网络框架Stripes，立刻就引起了本人极大的兴趣。其实该框架在2005年就发布了，不久前发布了1。5版。让我感到意外的是国内业界似乎对其很少提及。
考试,大提示本文不嫌粗陋，对Stripes略加介绍，以期抛砖引玉。
软件的展示层（presentation layer）是最麻烦的。以网络应用为例，软件的最终输出，须以符合html的要求。此外，尚需对html元素进行修饰和定位，这就用到了CSS技术。
如果进一步，可能尚需dhtml和Ajax。也就是说，还需要应用JavaScript技术。
而网络框架的功能主要有两个：一是把程序数据以后台软件组件（如ActionBean等）的形式注入到展示层；同时把展示层传入的用户动作导入到后台组件，激活业业务处理等。
二是提供页面浏览定义功能。说白了，就是把展示层与后台组件合理有效地搞到一起。
这有个问题，由于展示层用到了较多的技术，网络框架应该尽可能保持透明，不要扭曲乃至掩盖了这些基本技术。然而Struts，JSF等显然没有满足这一要求，很显然，它们都搞得太狠了，有个词叫Over Engineering。
它们提供了太多的标签（tag lib），他们不知道Tags就是API。大家学习html tags是心甘情愿的，因为html是标准和通用的；但学习个别框架的tags就很抵触。如果打开一个jsp源代码，里面到处都是框架的tag，这就太让人头痛了。
可以想象，这个公司用Struts，那个公司用JSF，对于开发人员来说将是多么痛苦的一件事，这是两套API啊！
另一个突出的问题便是配置文件。自从xml兴起，配置文件就成了第一头痛的问题。可以说，xml不论是对人还是对机器，都是不友好的。
但Java社区过去片面追求灵活性（flexbility），低耦合（loose coupling）及其它诸多不切实际的华丽词藻，xml配置文件满天飞。以Struts为例，你可能要配置form数据，navigation数据，validation数据等等。
你可以想象，一个中等规模的网络应用的相关配置文件将会是如何庞大。这还没有记入后台其他组件的配置文件。真让人不禁无奈地摇头感叹：写代码容易，让j2ee程序转起来难，搞定配置文件更难。笔者曾感叹过：我们是用Java写程序还是用xml来写程序？！
如果留心观察，Spring的兴起，无非是借了EJB2的东风。
因为后者太繁琐了，尤其是配置问题和资源注入方式。而EJB3的兴起，则是实事求是，总结了EJB2的经验，吸取了Spring的优点。EJB3最显著的改进便是将xml配置文件一扫光！而用annotation取而带之，并提供合理的缺省值。
很明显，下一个成功的网络开发框架，必然要在透明度，配置，后台资源注入等等方面有一个质的飞跃。这当然需要广泛采用annotation技术。另一个最重要的要求，就是力求“简单”。在本人看来，Java业界的最主要的问题之一就是搞得太狠，over engineering！
好了，说了半天，似乎没有涉及Stripes，其实不然。
Stripes在配置（不需要自己的配置文件），资源注入，validation，透明度等诸多方面均令人满意。而且很容易与EJB3或Spring等结合。Stripes的tag及annotation的数量很少，很容易上手。
为什么要学习一个新的框架呢？
如果你花了很多时间在Struts，JSF，或WebWork上，那很可怜。当然，有很多时候我们身不由己，不能选择。但本文相信只有好的东西才值得学习。就如同EJB2到EJB3的变迁，Stripes就好像网络开发框架（web framework）中的EJB3，它简单，直观，实用，高效，灵活。
不管你怎末看，本文相信Stripes将在不久成为主流网络开发框架。收起
