实际上，业务过程中，往往是一个Action不能完成任务的，比如：一个登录，则要进行密码验证，然后密码正确到正确的页页，不正确，到错误提示页面。
这种情况怎么实现呢？？
本框架中提供了Action处理树，可以根据执行情况一步步地执行的正确的结果...
请看下一回复
Action提供了嵌套配置方法，这样，一个Action中可以有下级Action，成为一个Action树。
下级Action有触发条件，也就是下级的Action是不是执行依赖于上级Action是否触发他。
<WebActionVerifyPassword ClassName="snowrain.web.action.WebActionVerifyPassword">
<WebActionRedirect ClassName="snowrain.web.action.WebActionRedirect">
<ActionCondition>true</ActionCondition>
<FormatPattern ClassName="snowrain.format.FormatPattern">
<Parameters>
<needRecordSetData>true</needRecordSetData>
<SourceString>test.jsp</SourceString>
</Parameters>
</FormatPattern>
</WebActionRedirect>
<WebActionRedirect ClassName="snowrain.web.action.WebActionRedirect">
<ActionCondition>false</ActionCondition>
<FormatPattern ClassName="snowrain.format.FormatPattern">
<Parameters>
<needRecordSetData>true</needRecordSetData>
<SourceString>error.jsp</SourceString>
</Parameters>
</FormatPattern>
</WebActionRedirect>
</WebActionVerifyPassword>
每个Action可以设置一个触发条件ActionCondition...
因此上面Xml描述了一个Action逻辑：
先验证密码，如果正确，则到test.jsp，否则到error.jsp。
辛苦了，能不能写成一个word文档或txt文档，使用发帖时的FIle上传，这样看得比较整体一些。
无论如何支持一下！！！！
1. ^χС
2.可以W下你的framework ?
3.提醒cdorado,eXtreme有什麽萘?
等下，正和banq商量，看他帮不有开一个专版？
其实不一定是最好，也一定有非常有许多要完善的地方，但是，放出来，大家总是有好处的，或是教训，或是长进。
建议开个专栏
绝对支持!那怎么处理与Jdonframework 的关系了?有钱的话还是自己搞个地方吧!
如果BanQ是一个比较热情，比较容易接受其它思想的人，会比较支持；
如果他是一个比较保守的人，应该不会支持，但也不会禁止；
如果他是一个比较自我的人，可能会禁止。
不过在我在Jdon中这么长时间看来,BanQ应该不保守，也不自我，不过有时有一些固执:)
一直支持的啊，今天又看了一下你的框架，感觉和tapestry差不多。
Tapestry使用了组件库概念替代了标签库，总得说来标签库的使用和配置要比组件库麻烦一些，特别不利于自己方便做一个标签库，条条框框限制比较多。
我感觉你好像还是使用标签库实现组件的概念，算是走了一个Tapestry和JSP的中间道理，象JSF一些。
近期我正在写一个Struts/Tapestry/JSF比较文章，敬请关注。
谢谢BanQ回复，你的感觉非常正确。因为你看到的部分正是我参考了tapestry的部分。
实际上我这个框架的发展分成两个阶段，第一个阶段，是全部内部组件技术，此时，全部是内容类实现，组件实现非常好，但是有一个不足的地方就是和jsp和html结合不好。
第二阶段，是全部内部组件的一个html标签库及taglib的支持。至此，整个展现部分强到极至：
<ui><li>可以用类缩写组件</li><li>可以用html制作组件</li><li>可以用xml配置组件</li></ui>
而且类组件、html组件、XML配置组件均可以互相访问，互相调用。
当然它们三者之间也是有一些区别：
<ui><li>类组件：适合于处理逻辑</li><li>html组件适合于制作效果</li><li>xml配置组件:适合于修改配置来改变组件表现</li></ui>
它和tapestry比较：
tapestry一个组件需要三个文件，我的框架只需要一个
tapestry的组件修改需要重新编译，我的框架不用
tapestry提供了缓冲，但是导致修改要重启框架，而如果不用缓冲，又慢得要命，而我的框架在效率方面非常之高，当然也内建支持缓冲
tapestry用原有的组件要合成一个新的组件，需要再重构一个组件，这样组件是重用了，但是陷入了不断的新组件的制作中；而我的框架所有的组件都可以被灵活组合成新的组件，组合过程可以是类组件，xml组件及html组件，只有类组件需要编写代码及编译。
tapestry原则上是和jsp关系的，当然不是说绝对不能相容，而我的框架，在jsp中也可以灵活使用。
因此，如果扣除细节实现上的问题，我觉得我的框架，比之tapestay还是非常有优势的。