1 如何安装
1.1 下载后，解包到你选择的目录
复制/lib/webwork.jar到你自己的web应用的/WEB-INF/lib目录下，webwork在某些功能方面需要依靠其他的支持包，这些包是在supporting-jars的文件夹里，你需要做的是把这些包包含到你的classpath中。
1.2 修改web.XML文件
修改web.xml文件以包含webwork的设置，如何设置的内容，请察看$WEBWORK/src/resource/web/WEB-INF/web.xml文件。
1.3 Taglib部分的选择
假如你不打算使用taglib、Velocity、或者XSLT，仅仅只需要在web.xml中不要包含这些内容就可以了。
1.4 Log的设置
Webwork使用log4j，假如你的app server没有安装log4j，你需要增加log4j，复制log4j.jar文件到合适的lib目录。假如你使用tomcat，那么安装目录是$TOMCAT_HOMElib，当然也可以安装到你的web应用的路径。但需要注重的是假如appserver也适用log4j，你需要小心版本冲突。
1.5 (可选)Javaclient
假如你打算在一个javaclient中使用webwork，那么需要将webworkclient.jar增加到你的client的classpath中，这将答应webwork使用ClientServlet的dispatch方法。另外client还需要引用log4j.jar.
到此，安装已经完成，你可以开始开发你的webwork的action和view了。来组建你的应用
2 设置webwork
2.1 Framework部分
2.1.1 基本配置文件
webwork和其他的mvc框架一样，通过设置property文件就可以配置webwork，通过配置文件，你可以设置webwork的行为。缺省情况下，webwork寻找两个property文件：webwork.properties和default.properties，来发现webwork.configuration.properties属性，这个属性的值是用来装载你实际配置webwork的配置文件。
webwork.configuration.properties的缺省值是：views,webwork,webwork/default.
这个用逗号分割的列表是告诉webwork去寻找views.properties、webwork.properties和default.properties属性文件。你可以在webwork.properties文件中定义任何属性设置来覆盖default.properties中的设置，也可以为你的应用定义新的属性值。还需要在views.properites中定义你的views。
下面是webwork识别的属性列表：
Properties
? webwork.action.packages - When you refer to actions in URLs, you may include the absolute or a relative package name. If you use a relative name, WW will prefix the name with your list of prefixes to see if it can find the action. You will normally override this property.
? webwork.action.factory - The action factory WW will use to retrieve the desired action. DefaultActionFactory is the default. It chains together factories to provide a chain of responsibility. It will ask the first factory in the chain for the action. This factory will either return the appropriate action or pass the request up the chain for the next factory to service the request.
? webwork.configuration - Class WW will use to load configurations. The default is DefaultConfiguration.
? webwork.configuration.properties - The list of property files WW will load. By default, WW will load webwork.properties and default.properties files to look for this property setting. It will then load all indicated property files and XML view config file indicated by webwork.configuration.xml. Only these last configuration files are used. By default this property is set to views,webwork,webwork/default.
? webwork.configuration.xml - The XML view configuration file. The default is actions. You can null it by setting its = to nothing if you do not plan to map your views this way.
? webwork.log4j.configfile - The configuration file to use to configure log4j logger. You can null it by setting its = to nothing if you do not want WW to configure log4j.
? webwork.action.extension - The extension WW will use to identify an action. You will need to modify your web.xml as well if you change it from the default “action.”
? webwork.multipart.parser - The parser WW should use for multi-part content.
? webwork.multipart.saveDir - The Directory WW should save the multi-part content to.
? webwork.multipart.maxSize - The maximum file size WW will allow for multi-part content
作为实例你可以参看缺省配置文件：default.properties.
2.1.2 如何覆盖一个属性
覆盖一个ww的属性是很轻易的，它在你的classpath路径中搜索webwork.properties文件。通常你可以将这个文件放在你的WEB-INF/classes目录下。在这个文件中，你增加你想要覆盖的属性。另外，你也可以增加你程序中需要使用的其他属性，并可以通过webwork.config.Configuration的静态方法来访问这些属性。
例如：我们可以在webwork.properties使用如下行，包含（Acme公司的action）来覆盖webwork.action.packages属性。
Webwork.action.packages=com.acme.action
2.2 Views
Views.properties文件定义了对应于Action或者jsp mappings的别名，这样可以答应你抽象的引用Actions和JSP。例如：你可以为testfoo.action定义一个别名为Test，那么ww将从views.properties中解析testfoo.action为Test.
<form action="<webwork:url page="testfoo.action"/>" method="POST">
下面列示的是一个views.properties文件的范例。注重：Test!foo定义了驱动action的命令，这意味着testfoo.action别名将导致ww获取Test action并调用doFoo方法。返回值是sUCcess，那么ww将解析别名testfoo.success并将test.jsp显示出来。
Testfoo.action=Test!foo
testfoo.success=test.jsp
假如你喜欢在xml文件中定义你的view。，而不是在一个properties文件中，那么你可以提供一个actions.xml文件来解决这个问题。缺省情况下，ww将读取该文件中定义的任何views，这里有一个actions.xml文件的实例。
这个xml文件的DTD文件是webwork的发布包的/etc/actions.dtd文件。
是使用如下得的算法来从配置文件中找到一个view的：
查询一个配置文件的actionName.viewName入口，若找到，就使用这个属性值，假如找不到，那么action的名称中就被移去部分，直到找到匹配项。例如：我们有如下的一个view mapping，并有一个foo.bar的action被执行，它的返回为success。Ww将要搜索foo.bar.success，然而，并不能找到匹配项。所以按照该算法。bar被移去，然后搜索foo.success，结果是找到。这答应你定义象login,error,success或任何你需要的得全局mapping。
foo.success=foo.jsp
2.3 Logger
Ww使用log4j来记录日志的，这是一个强大的弹性的日志器，为你的应用提供服务。Ww通过一个property文件log4j.properties来配置logger，如下：
# A log4j properties file
### The WebWork console appender
log4j.category.webwork=DEBUG,WebWorkConsole
log4j.additivity.webwork=false
log4j.appender.WebWorkConsole=org.apache.log4j.ConsoleAppender
log4j.appender.WebWorkConsole.Threshold=DEBUG
log4j.appender.WebWorkConsole.layout=org.apache.log4j.PatternLayout
log4j.appender.WebWorkConsole.layout.ConversionPattern=[%x (%c{1})] %m%n
log4j.category.webwork.action.test=INFO
2.3.1 如何在actions中使用log
大部分应用的actions是从基础action ActionSupport继续来的，这个基础action提供了一个protected的log属性给你，用来在你的actions中输出logs
2.3.2 如何将log记录到一个文件
用一个符合你需要的log4j配置来覆盖ww的webwork.log4j.configfile属性，你可以指定一个属性或者一个XML文件。
3 Model-1与Model-2
一个web应用的framework最重要的任务就是支持逻辑、内容、和表现层的分离，假如没有实现这些，维护起来是很麻烦的。假如这样进入小组开发，那么开发过程是很困难的。而实现这些分离的流行办法是采用MVC的设计模式，MVC的模式将这些代码分离成几部分来处理model（商业逻辑）、controller（应用逻辑）、view。随着这种分离，下一个问题就是controller如何和view之间进行交互。现在有两种流行的模型：Model-1和Model-2
3.1 Model-1
Model-1的基本思路是从界面层调用controller的代码。如：JSP或模版，假如你使用JSP，那就意味着webwork的action是通过“webwork:action”tag来执行的或通过使用“webwork:bean”来调用javabean来执行的。
3.2 Model-2
Model-2的方法：对于那些代码被调用，使用哪个view来显示，通常由第三方(通常是一个servlet dispatcher)，这个分发器（dispatcher）将对HTTP的请求的URL进行解码，然后决定应该执行什么代码。代表控制代码的java对象被找到并执行，然后进行一些自定义的应用逻辑和商业逻辑的处理，执行完成后，分发器（dispatcher）将forward访问请求到一个view处理器（如：JSP），然后前面处理的数据就被这个view显示出来。
3.3 如何使用MVC
因为controller逻辑和显示的产生是完全分离的，那么根据执行的结果而显示不同的view给用户是完全可能的，如：假如处理过程出错，那么一个错误页面将被显示出来。
Model-1的优点如下：
l 不需要在代码和显示间建立一个映射。
l 很轻易就能从JSP或模版中知道是什么代码被执行。
Model-2的优点：
l 清楚的代码和显示层的划分，同一个显示页可以被许多不同的action复用，每个action可以相异地访问数据，但使用相同的方式来显示。
l 假如Action的处理结果有许多不同的状态，如：“success”、“need more input”、“error occurred”等，那么使用Model-2就很轻松的针对不同的状态使用不同的叶面。
关于什么时候使用什么模式，一个简明扼要的规则是：在为显示而查询数据的read-type的代码，就使用Model-1，而对于数据被action更新或一个流程需要处理就使用Model-2。
4 Action API
Actions 是webwork的中心，是你应用的controller，例如：让我们来看一个表单发布的普通流程。用户输入信息并发布它，使用ww你应该将这个表单post给一个action（*.action）的URI。Servlet容器看到所有action URI被映射到分发器(dispatcher)servlet。所以这个post也被送到分发器来处理。分发器在URI的基础上找到合适的action并建立它的context，context建立好之后，分发器将调用action的执行方法，action将执行它的工作并返回一个字符串给分发器，让分发器用来决定什么视图应该显示给用户。大多数情况，你将返回SUCCESS, ERROR, INPUT, 或者 LOGIN。为完成这些你需要提供一个view mapping entry来将这些映射到view。
Ww需要所有的action有相应的view，但这个规则有2处例外，第一个是：假如你的action是一个chain中的一部分，那么你不需要相应的view，只有chain中的最后一个action需要一个view。第二个例外是：假如你的action返回NONE，这是一个非凡的标示。Ww用来指示分发器不要forward这个请求到一个view。这个假设是你提供任何请求的必须的处理,如:respond.sendRedirect()。
Action的强大功能来自于它的context，当得到一个action，那么它的context由DefaultActionFactory来构建，这个类将其他设置action的context的factories链接在一起。例如：假设你的action是一个java action，缺省action factory将委派查找action给ParametersActionFactory，这个类将又委派给下一个factory，依次往下委派。直到JavaActionFactory 来处理这个调用并返回 Java action. ParametersActionFactory 然后在request的参数的基础上设置这个action的所有 setters .。而各层次的factories可能也可能不参与设置这个action的context。某个factories 是通过检查一个marker接口来决定是否参与设置action的context。. WW 提供了几个 marker 接口，action可以有选择的来实现 that an action may choose to implement. 另外，这些层次的 factories 答应你从Java, JSP, javascript, 和 XML 文件来创建action. 但是，大多数情况下你的action是继续自ActionSupport 的Java文件。
（未完待续）
