DynaActionForm
DynaActionForm提供了一种方便的机制从根本上消除了编写ActionForm的需要DynaActionForm可允许动态的表单属性这意味着你能够在你的strutsconfigxml文件中定义属性并且将表单类型设置为orgapachestrutsactionDynaActionForm什么都不需要写DynaActionForm使用Apache公共项目中的DynaBean完成这些操作这一动态的行为是通过反射（reflection）与哈希图（Hashmaps）提供的
DynaActionForm是在strutsconfigxml文件中使用与标记定义的如下所示
动态表单的属性与标准的ActionForm的属性类似属性name是用于索引Action中的表单bean并且type用于指定实例化的类当使用类DynaActionForm时的动态属性自动默认为真（true）对于DynaActionForm要用元素指定表单的所有属性元素中的name是指属性名称type是指bean属性用Java的实现类的类名如果这个属性是索引类型的可在type后添加[ ]在上表中你应该注意最后一个属性genre的定义我们设置了初始值（或叫 默认值）为Dance这个值也会在DynaActionForm中reset()方法被调用时被作为默认值设置并允许在表单中设置默认值的机制如果在initial属性中没有指定任何值那么所有原始类型的初值被设置为如果是对象则初值为null（空）使用DynaActionForm非常方便主要的一个好处就是你只需写非常少的代码就像其他表单一样前面的代码例子是使用表单所需的全部代码需要知道的一件事就是验证当使用DynaActionForm时假定在某处进行了验证处理这与ActionForm有些不同你可以在自己的Action中实现验证但这是一个更好的方法
进行验证可用DynaValidatorForm或者DynaValidatorActionForm这两个类都在orgapachestrutsvalidator package包中通过扩展DynaActionForm可以得到基于XML文件的基本值域的验证验证是基于输入验证器的keyKey是来自于strutsconfigxml文件的name属性它应当与validationxml文件中的表单元素的name属性匹配
多应用支持
在Struts 中可以定义和支持多重的子应用这意味着你能将你的应用放在更易维护的子应用中你不再需要在唯一的strutsconfigxml文件之外检测来源控制
另一个使用子应用的原因是根据客户而改变的控制流在某些应用中你可能有一些通用的页面但是控制流也许会由于登陆应用的客户的不同而有所改变你能把这个控制流的元数据存入数据库并生成webxml文件（或该文件中的一部分）与不同的strutsconfigxml文件一起
如果你曾对Struts x进行过开发你可能注意到了许多webxml文件中的元素已经移到了Struts 的strutsconfigxml文件中这是因为现在他们是应用特定（applicationspecific）的多重的子应用通过在请求URI的相对于上下文部分开始的前缀来确定如果没有应用前缀能够匹配则选择默认配置默认设置拥有一个空字符串的前缀执行默认设置的这种方式对可能只定义一个应用的Struts x是向后兼容的
如果你拥有一个包含不同功能模块的大型应用那么用协同运行的子应用代替一个巨大的应用会更有意义下面所示的文件webxml显示了如何定义子应用
config
/WEBINF/strutsconfigxml
config/catalog
/WEBINF/strutsconfigcatalogxml
config/sorter
/WEBINF/strutsconfigsorterxml
当使用子应用时你可能定义上下文相关的请求URI来指定使用哪一个子应用例如对表单的动作可能如下所示
引用了默认的子应用或
引用catalog子应用的动作类实际上你不必这么做你可以在catalog子应用中用/listCds如果你想这么做基本规则是所有在版本中上下文相关的strutsconfigxml参数现在在版本中是子应用前缀相关的这样在没有修改的情况下一个单一的应用既可以作为默认子应用也可作为指定的子应用
