Structs中基本配置入门

第一章Structs的基本配置
1.为Structs应用配置Web.xml文件
第一步:配置ActionServlet

action
org.appache.structs.ActionServlet



action
*.do

注意:不管应用中包含多少个子应用,都只需配置一个ActionServlet,因为ActionServlet支持多线程,目前的Structs框架只允许在应用中配置一个ActionServlet。
第二步：初始化参数对Servlet的运行环境进行初始化配置。

action
org.appache.structs.ActionServlet

config
/WEB-INF/structs-config.xml


表2-1. Struts1.1中用到的初始化参数
参数名 含义/默认值
config 以相对路径的方式指明Struts应用程序的配置文件位置。如不设置，则默认值为/WEB-INF/struts-config.xml。
config/sub1 以相对路径的方式指明子应用程序的配置文件位置，一般来说，很少用到子应用程序，在此不多描述。
debug 设置Servlet的debug级别，控制日志记录的详细程度。默认为0，记录相对最少的日志信息。
detail 设置Digester的debug级别，Digester是Struts框架所使用的用来解析xml配置文件的一个框架，通过该设置，可以查看不同详细等级的解析日志。默认为0，记录相对最少的日志信息。

第三步：配置欢迎清单
当客户访问Web应用时，如果仅仅给出Web应用的Root URL，没用指定具体的文件名，Web容器会自动调用Web应用的欢迎文件。

welcome.jsp
index.jsp

说明：可以包含多个子元素，首先查找第一个文件。
由于元素中不能配置Servlet映射，因此不能直接把Structs的Action作为欢迎文件，可以采用一种变通的方法来实现在欢迎文件中调用Structs Action。首先，在Structs配置文件中为被调用的Action创建一个全局的转发项，例如：



创建一个welcome.jsp的文件
最后在web.xml文件中把welcome.jsp文件配置为欢迎文件，代码如下：

welcome.jsp

第四步：配置错误处理


404
/commom/404.jsp


505
/commom/505.jsp

也可以为Web容器捕获的Java异常配置,需要设置子元素，它用于指定Java异常类。Web容器可能捕获如下异常：
RuntimeException或Error ServletException或它的子类 IOException或它的子类

java.io.IOException
/common/system_ioerror.jsp

第五步：配置Structs标签库
使用客户化的标签库，要配置它们

/WEB-INF/structs-html.tld
/WEB-INF/structs-html.tld

用于指定标签库的相对或者绝对URI地址，Web应用根据这一URI来访问标签库。
指定标签描述文件在文件资源系统中的物理位置。
2 Structs配置文件
Structs框架在启动时会读入其配置文件，根据它来创建和配置各种Structs组件。
1元素
元素是Structs配置文件的根元素，元素有8个子元素。它的DTD定义如下：

在Struts配置中，必须按照以上的DTD指定的先后顺序来配置元素的各个子元素，如果颠倒了这些元素的配置文件中的位置，在Structs应用启动时会生成错误。
元素



元素包含零个、一个或者多个子元素，用于配置特定的数据源，它可以包含多个子元素，用于设置数据源的各种属性。
。。。
配置了数据源后，就可以在Action类中访问数据源，在org.apache.structs.action.Action类中定义了getDataSource(HttpRequrst)方法，它用于获取数据源对象的引用。
DataSource dataSource;
Connection connection;
dataSource =getDataSource(request);
connection=dataSource.getConnection();
也可以在配置文件中声明多个数据源，此时需要为每一个数据源分配唯一的key值，通过改值来标识特定的数据源。
2元素
元素用来配置多个ActionForm Bean，包含多个子元素，,每个包含多个属性，ClassName , name,type



注意：配置动态ActionForm Bean，还必须配置元素的元素。







3元素
用于配置异常处理，元素可以包含零个或者多个元素。
元素用来设置java异常和异常处理类org.apache.structs.action,Exception Hander之间的映射。
4元素
元素用来声明全局的转发关系，有零个或多个元素组成。元素用于把一个逻辑映射到特定的URL
属性 描 述
className 和元素对应的配置类，默认为org.apache.structs.action.ActionForWard
name 转发路径的逻辑名，此项时必须的
path 指定或者重定向的URI。此项时必须的，必须以”/”开头
redirect 此项是true，表示是执行重定向的操作，此项是false时，表示请求转发。








如果jsp1.jsp把请求转发给Action1,可以使用以下代码：

或者
如果Action1的execute（）方法把请求转发给JSP2.jsp，可以使用一下代码：
return(mapping.findForward(“forward2”))
5元素
元素包含零个或者多个元素。元素描述了从特定的请求路径到相应的Action类的映射。
6元素
元素用于配置ActionServlet。
7<>元素
元素用于配置Resource Bundle，Resource Budle用于存放本地化消息文件。
Structs标签
HTML标签
标签名 描述
base 包装HTML的base元素
button 包装HTML的 button类型的input元素
cancel 包装HTML cancel 按钮
checkbox 包装HTML checkbox 类型的输入域
errors 有条件地显示一些error消息，显示ActionErrors信息
file 包装HTML文件上传输入域
form 定义HTML form 元素
frame 包装HTML frame 元素
hidden 包装HTML hidden 输入域
html 包装 HTML中的 html 元素
image 包装 "image"类型的输入域
img 包装HTML的 img 元素
javascript 包装根据ValidatorPlugIn提供的校验规则所提供的javascript校验脚本
link 包装超链接
messages 有条件地显示一些提示信息，显示ActionMessages信息
multibox 包装多选输入框
option 包装一个选择输入框
options 包装一批选择输入框
optionsCollection 包装一批选择输入框集
password 包装密文输入框
radio 包装单选输入框
reset 包装“重置”功能的按钮
rewrite 包装一个URL
select 包装一个选择输入框
submit 包装一个提交按钮
text 包装一个文本输入框
textarea 包装一个备注输入框

ActionForm
ActionForm 的要求
创建一个ActionForm 并不困难，但是你的类必须符合一些要求：
ActionForm 必须扩展自org.apache.struts.ActionForm。基类ActionForm 是不能实
例化的。
ActionForm 必须为每个应该从请求中收集的HTML控件定义一个公共属性。
(Struts 1.0 要求每个属性都要mutator 和accessor 。Struts 1.1 则没有如此严格)
ActionForm还可能要符合一些可选的要求:
如果你要求ActionForm 在传递属性到Action之前校验它们，你就必须实现validate
方法；
如果想在组装前初始化属性，必须实现reset , 它在ActionForm 组装前被调用；
动态ActionForm
ActionForm 作为类型转换器
ActionForm的一个强制点是应该使用String 和boolean属性。实际上，这意味着属性
必须得从一种转换到另一种类型。大部分应用也需要一些属性，比如电话号码或者数量，以
一种格式化的方式出现。核心Java 包提供一些工具来做这种事情，但是要清楚地将他们集
成到应用中仍然是一个挑战。
Struts 开发人员经常在ActionForm中包含helper方法，来进行类型转换。helper 方法
可以有很多种实现方式，这我们在5.6种叙述。
5.2.6 ActionForm 作为防火墙
当请求提交时，ActionServlet 使用一个自动组装机制来从请求参数中设置请求的
ActionForm属性。这让你可以通过控制哪个ActionForm 属性被暴露来控制哪个请求参数
是可接受的。这也意味着如果你的ActionForm 的粗心设计你可能失去控制哪个参数可以接
受的能力。ActionForm 一定不能包含看起来像是一个JavaBean 属性，但不能从HTTP 请
求设置的属性方法。
5.3.4 ActionForm 可以嵌套其它bean
因为Struts 标签扩展和自动组装机制都支持点号语法来从ActionForm访问其它
bean。这是一个方便的方式，可以通过ActionForm来组装存在的bean。在JSP 页面, 你可
以象这样引用一个嵌套的bean：

5.7.2 分发（Dispatch ）
Struts 开发人员通常使用同一个Action处理相关的操作。一个通常做法来选择操作是在
HTML表单中使用隐藏属性。BaseForm 的dispatch 属性也可用作这个目的：
public void setDispatch(String dispatch);
public String getDispatch();
Struts 配置提供连个级别嵌套的ActionForward:
Global （全局） ActionForward对整个应用中的所有Action 对象均有效；
Local （局部） ActionForward 则在ActionMapping 元素中定义。仅对那些在这个
ActionMapping中调用的Action对象有效。
从Action 对象内部来看，forward 通常像这样来选择：
ActionForward forward = mapping.findForward("continue");

你还在用if else吗？

面向过程设计和面向对象设计的主要区别是：是否在业务逻辑层使用冗长的if else判断。如果你还在大量使用if else，当然，界面表现层除外，即使你使用Java/C#这样完全面向对象的语言，也只能说明你的思维停留在传统的面向过程语言上。

传统思维习惯分析

　　为什么会业务逻辑层使用if else，其实使用者的目的也是为了重用，但是这是面向过程编程的重用，程序员只看到代码重用，因为他看到if else几种情况下大部分代码都是重复的，只有个别不同，因此使用if else可以避免重复代码，并且认为这是模板Template模式。

　　他范的错误是：程序员只从代码运行顺序这个方向来看待它的代码，这种思维类似水管或串行电路，水沿着水管流动（代码运行次序），当遇到几个分管（子管），就分到这几个分管子在流动，这里就相当于碰到代码的if else处了。

　　而使用OO，则首先打破这个代码由上向下顺序等同于运行时的先后循序这个规律，代码结构不由执行循序决定，由什么决定呢？由OO设计；设计模式会取代这些if else，但是最后总是由一个Service等总类按照运行顺序组装这些OO模块，只有一处，这处可包含事务，一般就是Service，EJB中是Session bean。

　　一旦需求变化，我们更多的可能是Service中各个OO模块，甚至是只改动Service中的OO模块执行顺序就能符合需求。

　　这里我们也看到OO分离的思路，将以前过程语言的一个Main函数彻底分解，将运行顺序与代码其他逻辑分离开来，而不是象面向过程那样混乱在一起。所以有人感慨，OO也是要顺序的，这是肯定的，关键是运行顺序要单独分离出来。

　　是否有if else可以看出你有没有将运行顺序分离到家。

设计模式的切入口

　　经常有人反映，设计模式是不错，但是我很难用到，其实如果你使用if else来写代码时（除显示控制以外），就是在写业务逻辑，只不过使用简单的判断语句来作为现实情况的替代者。

　　 还是以大家熟悉的论坛帖子为例子，如ForumMessage是一个模型，但是实际中帖子分两种性质：主题贴（第一个根贴）和回帖（回以前帖子的帖子），这里有一个朴素的解决方案：
建立一个ForumMessage，然后在ForumMessage加入isTopic这样判断语句，注意，你这里一个简单属性的判断引入，可能导致你的程序其他地方到处存在if else 的判断。

　　如果我们改用另外一种分析实现思路，以对象化概念看待，实际中有主题贴和回帖，就是两种对象，但是这两种对象大部分是一致的，因此，我将ForumMessage设为表达主题贴；然后创建一个继承ForumMessage的子类ForumMessageReply作为回帖，这样，我在程序地方，如Service中，我已经确定这个Model是回帖了，我就直接下溯为ForumMessageReply即可，这个有点类似向Collection放入对象和取出时的强制类型转换。通过这个手段我消灭了以后程序中if else的判断语句出现可能。

　　从这里体现了，如果分析方向错误，也会导致误用模式。

　　讨论设计模式举例，不能没有业务上下文场景的案例，否则无法决定是否该用模式，下面举两个对比的例子：

　　第一. 这个帖子中举例的第一个代码案例是没有上下文的，文中只说明有一段代码：

main() {
if（case A）{

//do with strategy A

}else(case B){

//do with strategy B

}else(case C){

//do with strategy C

}

}


　　这段代码只是纯粹的代码，没有业务功能，所以，在这种情况下，我们就很难确定使用什么模式，就是一定用策略模式等，也逃不过还是使用if else的命运，设计模式不是魔法，不能将一段毫无意义的代码变得简单了，只能将其体现的业务功能更加容易可拓展了。

　　第二.在这个帖子中，作者举了一个PacketParser业务案例，这段代码是体现业务功能的，是一个数据包的分析，作者也比较了各种模式使用的不同，所以我们还是使用动态代理模式或Command模式来消灭那些可能存在的if else

　　由以上两个案例表明：业务逻辑是我们使用设计模式的切入点，而在分解业务逻辑时，我们习惯则可能使用if else来实现，当你有这种企图或者已经实现代码了，那么就应该考虑是否需要重构Refactoring了。


if else替代者

　　那么实战中，哪些设计模式可以替代if else呢？其实GoF设计模式都可以用来替代if else，我们分别描述如下：

状态模式　
　　当数据对象存在各种可能性的状态，而且这种状态将会影响到不同业务结果时，那么我们就应该考虑是否使用状态模式，当然，使用状态模式之前，你必须首先有内存状态这个概念，而不是数据库概念，因为在传统的面向过程的/面向数据库的系统中，你很难发现状态的，从数据库中读取某个值，然后根据这个值进行代码运行分流，这是很多初学者常干的事情。参考文章:状态对象：数据库的替代者
　　使用传统语言思维的情况还有：使用一个类整数变量标识状态：


public class Order{

private int status;

//说明：

//status=1 表示订货但为查看 ；

//status=2 表示已经查看未处理；

//status=3 表示已经处理未付款

//status=4 表示已经付款未发货

//status=5 表示已经发货

}


　　上述类设计，无疑是将类作为传统语言的函数来使用，这样导致程序代码中存在大量的if else。


策略模式　
　　当你面临几种算法或者公式选择时，可以考虑策略模式，传统过程语言情况是：从数据库中读取算法数值，数值1表示策略1，例如保存到数据库；数值为2表示策略2，例如保存到XMl文件中。这里使用if else作为策略选择的开关。


command模式　
　　传统过程的思维情况是：如果客户端发出代号是1或"A"，那么我调用A.java这个对象来处理；如果代号是2或"B"，我就调用B.java来处理，通过if else来判断客户端发送过来的代码，然后按事先约定的对应表，调用相应的类来处理。


MVC模式　
　　MVC模式的传统语言误用和Command模式类似，在一个Action类中，使用if else进行前后台调度，如果客户端传送什么命令；我就调用后台什么结果；如果后台处理什么结构，再决定推什么页面，不过，现在我们使用Struts/JSF这样MVC模式的框架实现者就不必范这种低级错误。


职责链模式　
　　职责链模式和Command模式是可选的，如果你实在不知道客户端会发出什么代号；也没有一个事先定义好的对照表，那么你只能编写一个个类去碰运气一样打开这个包看一下就可以。与Command是不同在AOP vs Decorator一文中有分析。


代理或动态代理模式　
　　代理对象可以是符合某种条件的代表者，比如，权限检验，传统面向过程思维是：当一个用户登陆后，访问某资源时，使用if else进行判断，只有某种条件符合时，才能允许访问，这样权限判断和业务数据逻辑混乱在一起，使用代理模式可以清晰分离，如果嫌不太好，使用动态代理，或者下面AOP等方式。


AOP或Decorator模式
　　
　　其实使用filter过滤器也可以替代我们业务中的if else，过滤器起到一种过滤和筛选作用，将符合本过滤器条件的对象拦截下来做某件事情，这就是一个过滤器的功能，多个过滤器组合在一起实际就是if else的组合。
　　所以，如果你实在想不出什么办法，可以使用过滤器，将过滤器看成防火墙就比较好理解，当客户端有一个请求时，经过不同性质的防火墙，这个防火墙是拦截端口的；那个防火墙是安全检查拦截等等。过滤器也如同红蓝白各种光滤镜；红色滤镜只能将通过光线中的红色拦截了；蓝色滤镜将光线中的蓝色拦截下来，这实际上是对光线使用if else进行分解。



如图，通过一个个条件过滤器我们立体地实现了对信号的分离，如果你使用if else，说明你是将图中的条件1/2/3/4合并在一起，在同一个地方实现条件判断。
　　需要深入了解过滤器的实现细节和微小区别，请参考文章：AOP vs Decorator

OO设计的总结　　

　　还有一种伪模式，虽然使用了状态等模式，但是在模式内部实质还是使用if else或switch进行状态切换或重要条件判断，那么无疑说明还需要进一步努力。更重要的是，不能以模式自居，而且出书示人。

　　真正掌握面向对象这些思想是一件困难的事情，目前有各种属于揪着自己头发向上拔的解说，都是误人子弟的，所以我觉得初学者读Thinking in Java（Java编程思想）是没有用，它试图从语言层次来讲OO编程思想，非常失败，作为语言参考书可以，但是作为Java体现的OO思想的学习资料，就错了。

　　OO编程思想是一种方法论，方法论如果没有应用比较，是无法体会这个方法论的特点的，禅是古代一个方法论，悟禅是靠挑水砍柴这些应用才能体会。

　　那么OO思想靠什么应用能够体会到了？是GoF设计模式，GoF设计模式是等于软件人员的挑水砍柴等基本活，所以，如果一个程序员连基本活都不会，他何以自居OO程序员？从事OO专业设计编程这个工作，如果不掌握设计模式基本功，就象一个做和尚的人不愿意挑水砍柴，他何以立足这个行业？早就被师傅赶下山。

　　最后总结：将if else用在小地方还可以，如简单的数值判断；但是如果按照你的传统习惯思维，在实现业务功能时也使用if else，那么说明你的思维可能需要重塑，你的编程经验越丰富，传统过程思维模式就容易根深蒂固，想靠自己改变很困难；建议接受专业头脑风暴培训。

　　用一句话总结：如果你做了不少系统，很久没有使用if else了，那么说明你可能真正进入OO设计的境地了。（这是本人自己发明的实战性的衡量考核标准）。