自从年Apache Struts出现以来它在大多数的标准下都运行良好帮助开发出了许许多多基于Java的Web应用程序Struts是利用服务器端生成的HTML和客户端验证的Javascript的完美结合使开发和维护变得更加容易随着时间的推移用户对Web应用程序的要求不断增加Struts 几乎还滞留于原地给Web开发者留下了越来越多无趣的衔接代码如何才能建立一个完美的框架结合体呢？
Struts的前世今生
在JavaOne 大会上一些Struts的开发者们与Rich Feit（Apache蜂巢计划的提交者）还有一些Struts的用户共聚一堂讨论Struts的未来与会者提出了Struts Ti的项目它描述了这样一个框架能够集众家所长重新组合成一个堪称完美的框架可是Struts本身的问题出现了Struts 的代码库不适合大幅度的改进而它本身的特性设置也相当有限缺乏了像Ajax的快速和可扩展性
同样在JavaOne会上笔者还与Webwork的核心架构师Jason Carreira讨论了关于OpenSymphony WebWork 的项目探讨我们如何能更好地协同工作对于在XWork上进行开发笔者还是十分感兴趣的特别是它们核心的命令模式框架但Jason Carreira建议笔者直接在WebWork 上进行开发当我和Rich使用了最初几个Struts Ti的版本后我们决定采纳Jason的建议
我们认为Struts应该满足高级应用程序的需求并且在WebWork 框架中的开发经历也证明了这点Rich和笔者大多数时间都与一位WebWork 的高级开发者Patrick Lightbody一起工作在这段时期内Patrick和Spring WebFlow项目的创建者Keith Donald从各个角度考虑了关于一个全新的Web框架的构想希望能将它们结合在一起也就是将Keith的Spring WebFlow和Ted Husted与笔者的Struts以及Patrick和Jason的WebWork与Rich的Beehive结合在一起探讨了将这些平台结合到一个框架中的可能性
不幸的是细节方面的困难出现了Beehive和WebFlow无法将其压缩和转换方面的特性进一步融合同时还有项目的所有者商标以及身份等问题不久这个团队就解散了
我们不想就这样解散笔者和Ted（Apache软件基金会的成员）开始与Patrick（WebWork 的高级开发者）和Jason（Webwork核心架构师）探讨如何能让我们更好地合作Ted产生了Struts与WebWork合并的想法
由于Struts Ti还是基于WebWork设计的那么将WebWork的代码转向Struts项目并不是件难事我们在一月开始了关于WebWork 的Apache Incubator进程并完成了WebWork 代码
Struts 的由来
同时Struts本身也在为项目的核心识别进行了激烈的竞争到底它是不是多重Web框架Struts包括了Apache Shale它是一个包含了JSF的Web框架作为一个Struts的子项目有着Struts Action （现在称之为Struts ）与Struts Action （完成了的WebWork 代码）的一些特征不幸的是这些子项目让开发者们有些混淆不清他们都用一个单一框架表示Struts
在尝试将Struts Action 与Shale的子项目结合到一个单独的Struts 之后Shale的开发者意识到如果这些能成为他们以后工程中的开发框架也是不错的选择Struts Action 很快就更名为简洁的Struts
如今Apache Struts项目已经有它的框架的两个主要版本但它仍是一个基于Action的框架项目并且WebWork仍然在定期发布程序补丁直到Struts 达到GA或是最终稳定但所有新的开发却都是使用Struts 代码
由此看来想要在Struts与WebWork的合并中寻找什么奇迹是不可能的还是另寻途径更好但是我们不会放弃当初Struts Ti的构想为将来做出一个集众家所长的完美框架而努力
