代码擂台，特别有请buaawhl

这个强大倒不是因为velocity,是spring对view层的强化。对于所有它支持的view类型都可以那么做。
如果风格变化太大，肯定需要就重新去搞那个变化的部分。可以把这个变化部分独立出来变化。其余部分仍然可以保持。这个时候需要权衡重用和重写的代价。
不过，我看fastm中的那个模板此时也是需要变化的

呵呵，看看我的fastm plus吧。就是加了一层的。

其实采用什么技术都不是最重要的，关键是你能够先完成任务，在可以多的时间可以考虑优化一下。
框架是比较成熟的技术，有许多人使用、优化，后期的维护和扩展性较好。
没有绝对的好，学习框架和熟练掌握需要付出努力和时间。在有可能的时候可以借鉴一下框架的思路，扩展一下编程的视野。

对了。charon.
这就是fastm的要义所在。这种情况下，fastm的Template有多少份都没有关系。但ValueSet DOM的处理代码只有一份。页面处理逻辑只有一份。
fastm的精义就是为了重用页面逻辑部分。Velocity的页面逻辑无法重用。

假如你能够暂时放弃“显示逻辑只应该存在于模板的脚本中，不应该存在于其他地方”的观点，试着理解我的观点。

而fastm做的事情不过是把页面逻辑从模板中移到了Java中。
大家对于模板脚本的执著，真的是我从前意料不到的。
但大家反对fastm的理由主要是，“显示逻辑只应该存在于模板的脚本中，不应该存在于其他地方（比如Java Code）”。

这个“只应该”和“不应该”，让我感到无能为力。
我只能想，
模板脚本什么时候出现的，出现之前是什么情况？
什么时候模板里面加入逻辑脚本成为了“应该”？
什么时候，显示逻辑成为了模板脚本的“只应该”专利，而其他方式都是“不应该”的？
如果这个“只应该”和“不应该”是绝对真理，那我确实无法为fastm辩护了。

看了大家对fastm, 以及显示控制代码的归属问题的讨论. 感觉fastm应该属于页面显示与业务操作的中间地带, 一个处理页面显示状态和业务操作状态交互的地带. 这似乎也就是MVC中C应该做的一部分工作. 将这份工作彻底地从JSP中独立出来应该就是fastm的目标了;-)  目前还没有什么实践的结果可以证实这样的确可以减少代码量, 增加重用性等. 但也不是不可取. 我还是会关注的.

一个建议: 把模板变量与EL或ognl相结合, 这样可以比较好的利用现有资源.

但是这种情况太少见了。风格的变化通常是用css来实现的，修改的是全局的那个css文件。至于从table变到list的变化，那么说，fastm重用了"所谓的显示逻辑"(后面我会解释为什么是所谓的)，而实际上模板部分的copy&paste还是很多的。和velocity的做法没有两样。
fastm还存在着更多的限制。如果你的显示逻辑变化，比如着色、字体，而且这类变化和动态内容相关，则必须在java代码中搞定。fastm在这个时候要比velocity的可维护性要差。
mvc的好处就是数据归数据，显示归显示。fastm中显示跨了两端，导致显示方式的变化在两端都会造成影响。这点是很不利的。
还有一个比较重要的是，我看了fastm的脚本，最终得出的结论居然是和velocity的区别在于if/else。实际上begin...这个东西当内部变量是一个list时，和foreach就是一回事情，把需要重复的部分包围起来。也许向用户屏蔽是不是一个list有意义，但是仔细一想，在html的表式方法中，用户根本就是知道你这个变量需要输出一个记录还是一堆记录，从上下文就可以很明确的判断出来。而fastm输出单个变量的做法，比velocity麻烦很多，比jstl也麻烦，效果也是一样的。
最后的问题就是fastm在java端代码所带来的麻烦，完全就是因为缺少if/else引起的，但是，有了foreach的等价物，何必吝啬于if/else?

:-) 你分析的没错。
但我的blog文档里面已经详细介绍了fastm的设计思路和用法。
而且给出了详细的例子，就是为了说明这个实现原理和对应关系。

--------------
Template DOM和ValueSet DOM之间的节点对应关系如下：

Template DOM的变量节点和ValueSet DOM的变量赋值节点之间是一对一的关系。而Template DOM的动态块节点和ValueSet DOM的动态块赋值节点之间是一对多的关系，这是为了让动态块能够在页面中多次显示。
---------------

如果你需要多次（0 -- n）次显示，就用BEGIN-END DYNAMIC.
如果你只需要替换 变量，那么就 使用 {}。

这就是fastm模板所需要的所有定义规则。

另外，你看到了valueSet.setVariable()分开调用的情况。
但真正使用的时候，只是调用一个通用方法，把Object所有的相关属性都写到Valueset里面去。
那么代码只有一行，setVariables(valueSet,  object);

另外，Java Code的风格你随便组织。
你可以把相关的设置都放在同一行。你也可以用很短的变量名。

其实前面我说的过程有些错误。
情况应该是，
JSP, Velocity程序员拿到不同风格的HTML, WML之后，在把那些相同的逻辑脚本填充到不同的HTML和WML中去。

另外，我觉得这种情况太常见了。
数据表格之间的关联关系很复杂。

同一个表有可能被多个表引用，作为那些表的公用属性。
那些表都需要在自己的界面显示这个关联表的数据。
而且通常情况下，由于每个表字段的多少不同和布局的不同，显示关联表的布局风格位置都不一样。

这个不算太复杂的东西。一般而言我们都是在主表中显示所有数据，客户是觉察不到有附属表的。
如果确实需要单独显示，也是由显示主表的页面确定附属表的位置和布局，其他需要动态确定的东西都可以在设计附属表显示模板的时候当作参数抽取出来。

一直关注这个讨论，但最近太忙，没有时间动手试验，只能停留在关注、思考阶段。

我的观点比较倾向于庄伟表等桶子，觉得fastm作为一个高度精简的模板机制，其html可读性、DOM等都是很好的思路。但是，因为“显示代码全部都在java中”，所以，应用起来可能需要更多的“修改－编译－重启”动作。

如果加入一个中间层次，我是说一个配置文件或者ognl等，总之就是尽量达到1.“封装显示逻辑”，2.无需“更改－编译－重启”，这两个目标。

如果这样的话，页面布局被封装在html中，而且仍能被wysiwyg。数据逻辑被封装在java代码中，能保持相对的稳定。显示逻辑被封装在这个新加入的中间层中，能够方便的调整。让这三个层次和谐共存彼此互不影响。

“简化我们的生活”？呵呵，这永远是我们的梦想。