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