对于HTML标签，使用自定义的org.apache.struts.taglib.html.FormTag为action属性动态生成动态URL可以保护HTML文档避免修改虚拟目录或时的大量变动。对于*.do模式的URL，下面的自定义FormTag  RM action="/editCustomerProfile?customerType=preferred"> 将使用action属性包含的如下服务器相关URL动态生成一个HTML 标签：

使用name属性，行为映射可以声明一个特定的JavaBean ，其特性将保存来自HTTP请求的参数，该JavaBean是ActionFrom类的子类。行为映射声明中的name属性是在特定范围内使用哪个ActionForm类的实例保存的唯一标示。ActionForm子类使用标签声明于struts-config.xml文件中，如下：

参阅“获取表单数据”章节以得到关于元素和ActionForm类的更多信息。

模型与请求处理器的相互作用

  Action的一个子类是用于作为提交的请求和模型之间的适配器。Action子类，也叫做请求处理器，是为每个请求特别建立的。一个动作最初被RequestProcessor解释，然后轮流实例化一个相应的请求处理器。这个Action类的对象为每个请求特别建立，已经在前面章节中的发送者阐述。请求处理器实现了命令模式[Gof]。一个终端请求在请求URL中封装了欲执行的行为即servlet路径，该路经信息随后被发送者（RequestProcessor）提取以建立一个相应的请求处理器实例。命令模式消除了用户界面（UI）对请求处理器的影响。

  基本的Action类提供访问架构相关资源的常用函数以及保存使用其子类的execute(…)方法而产生的错误的方法。该错误随即通过采用定制的org.apache.struts.taglib.html.ErrorsTag，被获取并显示到HTML表单。请求处理器的execute(…)方法应该包含处理请求参数和相关ActionForm的控制流程，它应该封装模型相关语义，并且应该在模型操作结果的基础上提供下一个视图。请求处理器在第一次建立后就被RequestProcessor捕获，随即被设为对其他的提交请求可用；同样的，请求处理器必须不含有用户特定的状态信息；请求处理器也必须同步化访问需要串行访问的资源。对于一个分布式应用，动作类包括与EJB组件中的事务逻辑相关联的控制逻辑且一般采用Business Delegate[Core]对象来实现该目的。事务委托保护请求处理器免于处理访问分布式组件的复杂度。因为访问服务器端组件的逻辑被嵌入到事务委托中，事务委托设计模式促进了请求处理器与服务器端组件的松散耦合。请求处理器由表示层工作的开发者编写，然而事务委托常常由负责建立事务层服务的开发者编写。对于小型非分布式应用，动作类或许包含事务逻辑。当分布式处理不是必需的且事务逻辑被嵌入在请求处理器中时，Data Access object [Core]可以用于抽象潜在的数据访问实现，它为请求处理器与数据访问层提供了松散的耦合，从而保护表示层避免在整合层中改变实现。请求处理器基本的Action类提供部分方便的方法，请查阅api文档位于：http://jakarta.apache.org/struts/api/index.html。

（待续...）