美国高级工程师谈Struts 走向
程序员文章站
2022-03-22 18:09:20
...
自从2000年Apache Struts出现以来，它在大多数的标准下都运行良好，帮助开发出了许许多多基于Java的Web应用程序。Struts是利用服务器端生成的HTML和客户端验证的Javascript的完美结合，使开发和维护变得更加容易。随着时间的推移，用户对Web应用程序的要求不断增加，Struts 1.0几乎还滞留于原地，给Web开发者留下了越来越多无趣的”衔接”代码，如何才能建立一个完美的框架结合体呢？
Struts的前世今生
在JavaOne 2005大会上，一些Struts的开发者们与Rich Feit（Apache蜂巢计划的提交者）还有一些Struts的用户共聚一堂，讨论Struts的未来。与会者提出了Struts Ti的项目，它描述了这样一个框架，能够集众家所长，重新组合成一个堪称完美的框架。可是Struts本身的问题出现了，Struts 1.0的代码库不适合大幅度的改进，而它本身的特性设置也相当有限，缺乏了像Ajax的快速和可扩展性。
同样在JavaOne会上，笔者还与Webwork的核心架构师Jason Carreira讨论了关于OpenSymphony WebWork 2的项目，探讨我们如何能更好地协同工作。对于在XWork上进行开发，笔者还是十分感兴趣的，特别是它们核心的命令模式框架，但Jason Carreira建议笔者直接在WebWork 2上进行开发。当我和Rich使用了最初几个Struts Ti的版本后，我们决定采纳Jason的建议。
我们认为，Struts应该满足高级应用程序的需求，并且在WebWork 2框架中的开发经历也证明了这点，Rich和笔者大多数时间都与一位WebWork 2的高级开发者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 2的高级开发者）和Jason（Webwork核心架构师）探讨如何能让我们更好地合作，Ted产生了Struts与WebWork合并的想法。
由于Struts Ti还是基于WebWork设计的，那么将WebWork的代码转向Struts项目并不是件难事。我们在一月开始了关于WebWork 2的Apache Incubator进程，并完成了WebWork 2代码。
Struts 2的由来
同时，Struts本身也在为项目的核心识别，进行了激烈的竞争，到底它是不是多重Web框架，Struts包括了Apache Shale，它是一个包含了JSF的Web框架。作为一个Struts的子项目，有着Struts Action 1（现在称之为Struts 1）与Struts Action 2（完成了的WebWork 2代码）的一些特征。不幸的是，这些子项目让开发者们有些混淆不清，他们都用一个单一框架表示”Struts”。
在尝试将Struts Action 2与Shale的子项目结合到一个单独的Struts 2之后，Shale的开发者意识到，如果这些能成为他们以后工程中的开发框架，也是不错的选择。Struts Action 2很快就更名为简洁的Struts 2。
如今，Apache Struts项目已经有它的框架的两个主要版本，但它仍是一个基于Action的框架项目。并且WebWork仍然在定期发布程序补丁，直到Struts 2达到GA或是最终稳定，但所有新的开发却都是使用Struts 2代码。
由此看来，想要在Struts与WebWork的合并中寻找什么奇迹是不可能的，还是另寻途径更好。但是我们不会放弃当初Struts Ti的构想，为将来做出一个集众家所长的完美框架而努力。
编后：作者在其BLOG中声称，写作本文的目的是为了说清楚Struts 2.0项目的由来，以及为什么它包含了WebWork 2代码。合并的本身就是一件难处理的事，甚至在开源社区也能看到端倪，两个项目之间构成一个好的合并，是非常罕见的，且还需要经过争辩，同时也希望合并的热潮能遍布开源的世界。
Struts的前世今生
在JavaOne 2005大会上，一些Struts的开发者们与Rich Feit（Apache蜂巢计划的提交者）还有一些Struts的用户共聚一堂，讨论Struts的未来。与会者提出了Struts Ti的项目，它描述了这样一个框架，能够集众家所长，重新组合成一个堪称完美的框架。可是Struts本身的问题出现了，Struts 1.0的代码库不适合大幅度的改进，而它本身的特性设置也相当有限，缺乏了像Ajax的快速和可扩展性。
同样在JavaOne会上，笔者还与Webwork的核心架构师Jason Carreira讨论了关于OpenSymphony WebWork 2的项目，探讨我们如何能更好地协同工作。对于在XWork上进行开发，笔者还是十分感兴趣的，特别是它们核心的命令模式框架，但Jason Carreira建议笔者直接在WebWork 2上进行开发。当我和Rich使用了最初几个Struts Ti的版本后，我们决定采纳Jason的建议。
我们认为，Struts应该满足高级应用程序的需求，并且在WebWork 2框架中的开发经历也证明了这点，Rich和笔者大多数时间都与一位WebWork 2的高级开发者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 2的高级开发者）和Jason（Webwork核心架构师）探讨如何能让我们更好地合作，Ted产生了Struts与WebWork合并的想法。
由于Struts Ti还是基于WebWork设计的，那么将WebWork的代码转向Struts项目并不是件难事。我们在一月开始了关于WebWork 2的Apache Incubator进程，并完成了WebWork 2代码。
Struts 2的由来
同时，Struts本身也在为项目的核心识别，进行了激烈的竞争，到底它是不是多重Web框架，Struts包括了Apache Shale，它是一个包含了JSF的Web框架。作为一个Struts的子项目，有着Struts Action 1（现在称之为Struts 1）与Struts Action 2（完成了的WebWork 2代码）的一些特征。不幸的是，这些子项目让开发者们有些混淆不清，他们都用一个单一框架表示”Struts”。
在尝试将Struts Action 2与Shale的子项目结合到一个单独的Struts 2之后，Shale的开发者意识到，如果这些能成为他们以后工程中的开发框架，也是不错的选择。Struts Action 2很快就更名为简洁的Struts 2。
如今，Apache Struts项目已经有它的框架的两个主要版本，但它仍是一个基于Action的框架项目。并且WebWork仍然在定期发布程序补丁，直到Struts 2达到GA或是最终稳定，但所有新的开发却都是使用Struts 2代码。
由此看来，想要在Struts与WebWork的合并中寻找什么奇迹是不可能的，还是另寻途径更好。但是我们不会放弃当初Struts Ti的构想，为将来做出一个集众家所长的完美框架而努力。
编后：作者在其BLOG中声称，写作本文的目的是为了说清楚Struts 2.0项目的由来，以及为什么它包含了WebWork 2代码。合并的本身就是一件难处理的事，甚至在开源社区也能看到端倪，两个项目之间构成一个好的合并，是非常罕见的，且还需要经过争辩，同时也希望合并的热潮能遍布开源的世界。