无论是直接经验还是阅读文章或书籍，大多数人都熟悉Struts。 在本系列文章中，我们将从Struts的角度介绍Struts2的功能-通过迁移一个简单的应用程序。
在开始迁移过程之前，需要对Struts2有所了解。 本文的第一部分将介绍Struts2，以及一些核心体系结构差异，这些差异将有助于从概念上将所有内容组合在一起。 第二部分将介绍后端的迁移-深入了解操作之间的差异； 与行动有关的框架特征； 和动作配置。 本文的最后一部分将介绍用户界面。 我们将介绍该体系结构； 讨论UI组件，主题和标签； 并在我们的应用程序中崭露头角。
我的目的不是涵盖所有可用的迁移方案，而是从一个共同的起点入手，介绍Struts2中可用的概念和新功能。 掌握了这些知识，迁移任何大小的应用程序都是小菜一碟！
简介/历史
Struts的第一个版本于2001年6月发布。它的初衷是可以将JSP和servlet一起使用，以提供视图与Web应用程序的业务或应用程序逻辑之间的清晰区分。 在Struts之前，最常见的选择是向JSP添加业务和应用程序逻辑，或者使用println（）语句从servlet呈现视图。
自发布以来，Struts已成为Web应用程序的实际标准。 随着这种流行，功能得到了增强和变化-既可以满足对Web应用程序框架不断变化的要求，又可以将功能与不断增长的可用竞争框架相匹配。
为此，对于下一代Struts提出了一些建议。 在过去的一年中，最具凝聚力的两个选择是Shale和Struts Ti。 Shale是一个基于组件的框架，最近才成为自己的顶级Apache项目，其中Struts Ti延续了使Struts如此成功的前端控制器或模型-视图-控制器模式。
WebWork项目是Struts的一次革命，它是Struts代码的一个分支，用于引入可能与原始Struts代码不兼容的新思想，概念和功能-它于2002年3月首次发布。WebWork是一个成熟的框架，经历了几次次要和主要发布。
在2005年12月，宣布WebWork和Struts Ti将联合起来。 从那时起，Struts Ti成为Struts Action Framework 2.0，并且是Struts的后继者。
最后，应该指出，Struts和WebWork项目都不会消失。 尽管人们的兴趣很高，并且愿意提供开发人员，但是这两个项目都将继续进行-始终修复错误，并添加增强功能和新功能。
请求演练
在开始研究如何将应用程序从Struts转换为Struts2的低级细节之前，让我们通过遍历请求处理来了解新架构的外观。
在遍历请求生命周期时，您应该注意到一个重要事实-Struts2仍然是前端控制器框架。 您熟悉的所有概念仍然适用。
这表示：
- 动作仍将通过URL的
- 数据仍通过URL请求参数和表单参数发送到服务器
- 所有这些Servlet对象（请求，响应，会话等）都仍可用于Action
从高层次的概述来看，这是处理请求的方式：
请求的处理可以分为以下6个步骤：
- 框架发出并处理请求 -框架将请求与配置相匹配，以便知道拦截器，操作类和要使用的结果。
- 该请求通过一系列拦截器 -拦截器和拦截器堆栈，可以在多个不同级别上针对该请求进行配置。 它们提供对请求的预处理以及跨领域的应用程序功能。 这类似于使用Jakarta Commons Chain组件的Struts RequestProcessor类。
- 调用Action-创建action类的新实例，并调用为该请求提供逻辑的方法。 我们将在本系列的第二部分中对此进行更详细的讨论。 但是，在Struts2中，操作的配置可以指定要为此请求调用的操作类的方法。
- 调用 Result-获得与处理操作方法的返回结果匹配的结果类，创建并调用新实例。 处理结果的一种可能结果是呈现UI模板（但不是唯一的一种）以生成HTML。 如果是这种情况，则模板中的Struts2标签可以返回到操作中以获得要呈现的值。
- 请求通过拦截器返回 -请求以相反的顺序通过拦截器，从而允许执行任何清理或其他处理。
- 响应返回给用户 -最后一步是将控制权返回给servlet引擎。 最常见的结果是将HTML呈现给用户，但也可能是返回了特定的HTTP标头或调用了HTTP重定向。
您可能已经注意到，存在一些差异。 最明显的是Struts2是pull-MVC架构。 这是什么意思？ 从开发人员的角度来看，这意味着可以从操作中提取需要显示给用户的数据。 这与Struts不同，Struts的数据应该存在于HTTP页面，请求或会话作用域中的bean中。 可以从其他地方提取数据，当场景出现时，我们将讨论这些地方。
配置框架
第一个也是最重要的配置是在servlet容器web.xml文件中启用Web应用程序框架的配置。
每个人都应该熟悉的Struts配置是：
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
对于Struts2，几乎没有更改。 最重要的是，调度程序已从servlet更改为servlet过滤器。 该配置与servlet一样简单，如下所示：
<filter>
<filter-name>webwork</filter-name>
<filter-class>
org.apache.struts.action2.dispatcher.FilterDispatcher
</filter-class>
</filter>
<filter-mapping>
<filter-name>webwork</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
与servlet配置类似，过滤器配置定义了过滤器的名称（供参考）和类。 过滤器映射将名称与将调用过滤器的URI模式链接在一起。 默认情况下，扩展名是“ .action”。 这在default.properties文件（在Struts2 JAR文件中）中定义为“ struts.action.extension”属性。
SIDEBAR ：“ default.properties”文件是定义许多配置选项的位置。 通过在Web应用程序的类路径中包含名称为“ struts.properties”的文件，并为这些属性使用不同的值，可以覆盖默认配置。
对于Struts，servlet配置提供了一个init-param标记，该标记定义了用于配置Struts的文件的名称。 Struts2没有这样的配置参数。 相反，Struts2的默认配置文件名为“ struts.xml”，并且需要位于Web应用程序的类路径上。
SIDEBAR / TIP ：由于Struts操作（带有“ .do”扩展名）和Struts2操作（带有“ .action”扩展名）之间存在命名空间分隔，因此没有理由不能将它们在同一个目录中共存Web应用程序。 这是开始迁移过程的好方法-添加必要的配置，并开始在Struts2中开发所有新功能。 只要时间和资源允许，其余的操作都可以转换。 或者，这两个框架可以永远和平共处，因为没有理由需要迁移现有的行动。 另一种迁移策略是通过将Struts2扩展名更改为“ .do”来仅更新操作。 这使现有的JSP保持不变并可以重复使用。
解构动作
在请求演练中，我们从较高的角度谈到了Struts和Struts2之间的一些区别。 现在让我们更进一步，看看每个框架中动作的结构之间的差异。
让我们首先回顾一下Struts动作的一般结构。 Struts操作的一般形式如下所示：
public class MyAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
// do the work
return (mapping.findForward("success"));
}
}
实施Struts动作时，您需要了解以下各项：
- 所有动作都必须扩展Action基类。
- 所有操作都必须是线程安全的，因为仅创建了一个操作实例。
- 因为操作必须是线程安全的，所以在处理操作中可能需要的所有对象都在方法签名中传递。
- 为执行操作而调用的方法的名称为“ execute”（Struts中有一个DispatchAction类，可以将要执行的方法重新路由到同一操作中的另一个方法，但是初始入口点从框架到动作仍然是“执行”方法）。
- 使用ActionMapping类中的方法返回ActionForward结果，最常见的是通过“ findForward”方法调用。
相反，Struts2动作提供了更简单的实现。 看起来是这样的：
public class MyAction {
public String execute() throws Exception {
// do the work
return "success";
}
}
您可能注意到的第一件事是该操作不会扩展任何类或接口。 实际上，它远不止于此。 按照惯例，在处理动作时调用的方法是“执行”方法-但不一定必须如此。 可以通过配置调用方法签名公共String methodName（）之后的任何方法。
接下来，返回对象是一个字符串。 如果您不喜欢代码中字符串文字的概念，则可以使用一个辅助接口Action来提供“成功”，“无”，“错误”，“输入”和“登录”的常见结果作为常量。
最后，也许与原始Struts实现最具革命性的区别是，在处理动作时调用的方法（“执行”方法）没有参数。 那么，如何访问需要使用的对象？ 答案在于“控制反转”或“依赖注入”模式（有关更多信息，Martin Fowler在http://www.martinfowler.com/articles/injection.html上提供了内容丰富的文章）。 Spring框架已经普及了这种模式，但是Struts2（WebWork）的前身大约在同一时间开始使用该模式。
为了更好地理解控件的反转，我们来看一个示例，在该示例中，操作的处理需要访问当前请求HttpServerRequest对象。
本示例中使用的依赖项注入机制是接口注入。 顾名思义，使用接口注入时，需要实现一个接口。 该界面包含设置器，这些设置器又用于为操作提供数据。 在我们的示例中，我们使用的是ServletRequestAware接口，这里是：
public interface ServletRequestAware {
public void setServletRequest(HttpServletRequest request);
}
当实现此接口时，我们上面的简单操作变得更加复杂-但现在我们有了一个HttpServerRequest对象。
public class MyAction implements ServletRequestAware {
private HttpServletRequest request;
public void setServletRequest(HttpServletRequest request) {
this.request = request;
}
public String execute() throws Exception {
// do the work using the request
return Action.SUCCESS;
}
}
此时，一些警钟可能正在响起。 现在，动作中具有类级别的属性-尽管不是线程安全的，但实际上还可以。 在Struts2中，将为每个请求创建一个动作实例。 它不共享，请求完成后将被丢弃。
还剩下最后一步，那就是将ServletConfigInterceptor拦截器与此动作相关联。 该拦截器提供了获取HttpServletRequest并将其注入实现ServletRequestAware接口的操作的功能。 目前，不必担心配置的详细信息-我们将在下一篇文章中详细介绍。 目前重要的是要了解拦截器和接口是携手工作的，以便为操作提供依赖项注入。
这种设计的好处是动作完全与框架分离。 该动作成为一个简单的POJO，也可以在框架之外使用。 对于鼓励单元测试的人来说，测试Struts2动作要比摔跤要使Struts动作进入StrutsTestCase或MockStrutsTestCase单元测试要容易得多。
结论/总结
到目前为止，您应该已经熟悉Struts2的基础知识-高级体系结构和基本请求工作流程。 您应该能够在servlet容器中配置Struts2，并且了解Struts和Struts2的操作之间的区别。
在下一篇文章中，我们将介绍将要迁移的示例应用程序，并基于此处获得的知识将示例应用程序的操作从Struts迁移到Struts2。 我们最终将得到一个使用JSTL，JSP和Struts2的有效应用程序。 我们还将进一步研究动作之间的差异； 行动和其他框架要素的配置； 并进一步讨论与操作相关的框架功能。
597
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
