struts相关

Web组件的三种关联关系
请求转发（forward）对客户透明，request里的信息保持。
请求重定向（redirect）重新request到新的URL
包含（include）

解决并行开发：
1、多个配置文件的支持（其实还是要合并，可能会引起forward冲突）
2、模块的支持ModuleConfig对应该模块的XXXConfig如ActionConfig、FormBeanConfig（考虑模块间的转发：forward或SwitchAction）

每写一个应用都用继承BaseAction和BaseForm，当然BaseAction最好是继承LookupDispatchAction，BaseForm最好是继承ValidatorActionForm

内置的Struts Action类
ForwardAction 无FormBean，直接forward到jsp
IncludeAction
DispatchAction
LookupDispatchAction //一个Action里多个操作
SwitchAction //多模块
利用Token解决重复提交

Struts的异常处理
主要捕获业务层的业务逻辑异常（最好自定义一下），业务层要捕获DAO层的异常(抛出统一的DataException异常，最好写入日志)

Struts的扩展（plugin）：如hibernate的初始化

Taglib的优缺点(学习有一定难度，web designer可能不熟悉)

资源文件的使用（多语言，用nativetoascii将非ASCII文本转为UTF-8）
所有html与jsp的ContentType设为UTF-8，另加上一个filter，根据客户的Locale对象设置相应的编码
<bean:message key="" />
ActionMessage与<html:errors>
关于资源文件(MessageResources)
ü         如果没有配置，则默认为WEB-INF/classes目录下的ApplicationResources.properties

ü         如果在struts-config.xml作了<message-resources parameter="xxx.yyy"/>则将默认的资源文件指定为WEB-INF/classes/xxx目录下的yyy.properties

ü         如果在struts-config.xml作了<message-resources key= "res" parameter="xxx.yyy"/>则将默认的资源文件指定为WEB-INF/classes/xxx目录下的yyy.properties，但是指定了引用bundle为"res"，这样struts validator的客户端验证就找不到相关资源

ü         可以配置多个资源文件

<bean:write name="" property=""/>
共享常量的处理(存放常量的Constants.java文件)

解决ActionForm问题（页面增多，急速增加，可能同一类型页面字段会在不同的ActionForm中出现，且验证代码重复）
1、一个模块或相关页面对应一个ActionForm（聚合，复用性差）
2、DynaActionForm（配置文件中配置，实际将属性存在一个HashMap类对象中，故get时要强制转换）

Action注意
1、视图级(表单)验证（用javascript也可以）在ActionForm中完成（如输入不为空，e-mail格式是否正确等），业务相关验证在Action中(可能会涉及到Model)，这样可以获得最大的ActionFrom重用性
2、主张将业务逻辑执行分离到单独的JavaBean中，而Action只负责错误处理和流程控制，并且在执行业务逻辑的JavaBean中不要引用任何与Web应用相关的对象，如Request、Response等，应该将其转化为普通的java对象(比如传递业务值对象VO)，可以参考petstore的WAF框架。

Form Bean 是Web层的数据表示，他不能被传递到业务层；PO是持久层的数据表示，在特定情况下，例如Hibernate中，他可以取代VO出现在业务层，但是不管PO还是VO都必须限制在业务层内使用，最多到达Web层的Control，绝不能被扩散到View去。
Form Bean 和PO之间的数据转化是在Action中进行滴。
不过由于Hibernate的强大功能，例如动态生成PO，PO的状态管理可以脱离Session，使得在应用了Hibernate的J2EE框架中，PO完全可以充当VO，因此我们下面把PO和VO合并，统称为PO

Struts框架的异常处理机制
包括ActionServlet类、RequestProcessor、ExceptionHandler类处理异常的机制
宣称式异常处理(一般是全局异常，如登录失败等)
在配置文件中指定谁来处理Action中抛出的异常，需要实现ExceptionHandler子类，覆盖execute方法。

 

Commons Logging 接口

所谓的Commons Logging接口，是指将日志功能的使用与日志具体实现分开，通过配置文件来指定具体使用的日志实现。这样你就可以在Struts 1.1中通过统一的接口来使用日志功能，而不去管具体是利用的哪种日志实现，有点于类似JDBC的功能。Struts 1.1中支持的日志实现包括：Log4J，JDK Logging API， LogKit，NoOpLog和SimpleLog。

你可以按照如下的方式来使用Commons Logging接口(具体日志实现在commons-logging.properties中声明)（可以参照Struts源文中的许多类实现）：

package com.foo;
// ...
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
//...
 public class Foo {   
 // ...   
 private static Log log = LogFactory.getLog(Foo.class);
 // ...   
 public void setBar(Bar bar) {      
  if (log.isTraceEnabled()) {        
   log.trace("Setting bar to " + bar);  
  }     
 this.bar = bar;  
 }
// ...
}

 

而开启日志功能最简单的办法就是在WEB-INF/classes目录下添加以下两个文件：

commons-logging.properties文件：

# Note: The Tiles framework now uses the commons-logging package to output different information or debug statements.
Please refer to this package documentation to enable it. The simplest way to enable logging is to create two files in
WEB-INF/classes:
# commons-logging.properties
# org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
# simplelog.properties
# # Logging detail level,
# # Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
#org.apache.commons.logging.simplelog.defaultlog=trace
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

 

simplelog.properties文件：

# Logging detail level,
# Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
org.apache.commons.logging.simplelog.defaultlog=fatal

 

这里我们采用的日志实现是SimpleLog，你可以在simplelog.properties文件指定日志明细的级别：trace，debug，info，warn，error和fatal，从trace到fatal错误级别越来越高，同时输出的日志信息也越来越少。而这些级别是和org.apache.commons.logging.log接口中的方法一一对应的。这些级别是向后包含的，也就是前面的级别包含后面级别的信息。