代码擂台，特别有请buaawhl

多谢鼓励。
fastm当然可以支持{姓名}这样的中文变量。
但你要在代码中这样写。
valueSet.setVariable("{姓名}", "Xiaohanne");
如果你的IDE支持中文，这是没有问题的。
当然，如果你的文件编码方式不是Unicode，也许你要考虑Encoding和Decoding的问题。

“本来想用taglib实现的，不过没时间做，”
:-)  JSF好像就可以 显示 TagLib。
还有一些其它的TagLib显示插件，能够显示某些TagLib。

看了你下面的代码我就知道可以做到，所以我编辑掉了

我觉得无论哪一种view的方式都不是很重要。我过去用过struts + jstl（最早的时候是struts自己的标签库，比较痛苦）, 现在用的是spring + velocity. 只不过感觉velocity简洁一些，没象jstl那么罗嗦（但是新版本的据说也变得很简捷）。
这里比较关键的一点是我用jstl也好，velocity(或者freemarker)也好，只是用来显示已经准备好的模型内的东西，这些模型数据本来就是以自然方式组织的，如果使用类似于fastm的方式，势必需要重新组织一边。但是好像缺乏一种统一的组织方式，必须每个定制。这个是为了简化前端而付出的代价。
  至于velocity的时间显示，以前要找一个格式化对象( 在jakarta/commons下好像有一个)，现在好像直接支持了，这个倒不是问题。倒是有一个挺有意思的问题，如果数据量较少（<200条记录）, 并且相对静态的话（这个根据业务需求决定），我们倾向于按请求时刻的快照进行分页显示以保持一致性（当然可以搞一个定时刷新的机制）。此时主要用javascript来实现，但是为了简化script的编写，也会用velocity进行预分页，由script根据点击显示不同的页面。此时，如果没有一定的逻辑控制，比如fastm,这个就必须在后端来干这个活。
  这个例子有点极端。一般说来，显示逻辑所解决的那部分问题，绝大部分是与显示相关的脏活。页面里面没有显示逻辑确实很好，但是这个脏活肯定得有东西来干，如果让后端代码来做，那就太糙了。或者说，等到应用部署以后，如果需要修改显示相关的东西，我宁可改前端页面，也不愿意去改动后端代码，毕竟，后者属于一种更加稳固的东西，改起来也麻烦很多。从解藕的观点来看，fastm的这种做法是一种倒退。

我不大清楚你说的什么叫做后端代码？JSP、JSTL、Velocity 里的代码不是在后端运行的吗？
按照我的理解，前端代码就是在浏览器中运行的那些 JS 代码。

我习惯于把整个view端从逻辑上看作前端，而不理会它的物理位置。因为mvc中的mc的变化是需要编译的，而v在廋客户端中一般只是脚本，不需要显式编译，属于所改即所得。而在胖客户端中，可能有很大一部分物理上就在客户端了。

对于fastm,我还有两个问题：
1 怎么实现常见的表中的行杂色显示，比如单数行一色，双数行另一色。因为在前端模板中没有逻辑控制，是不是只能在后端的java程序中搞定。
2 多条记录的分页打印问题。比如打印200个人的工资单。要求每15个人制一张表，所有14张表都在一个页面里面同时显示(那样只用点选一次打印菜单就可全部搞定)，各表之间需要插入分页符号。这样的一个纯粹的显示逻辑，在模板没有逻辑控制的情况下，是不是连分页符号(css相关)也需要在java代码中设定？这个和那个快照分页差不多，但是业务含义要更明确。
或者说，在fastm情形下，是不是连页面的某些格式成分也必须在java端设定？这样的话，是不是更加混乱了？

我在这个主题的前面发了一个贴子，讲了MVC的来龙去脉，以及MVC造成的思维定势问题。可以解答你的问题。

下面，我们继续深入探讨一下。不知道你用过Swing没有？
你觉得Swing好用，还是JSP好用？
为什么现代Web Framework都要模拟Swing，把页面组件和后端事件绑定起来？
你觉得JSP更像Swing，还是fastm更像Swing？

JSP需要知道每个具体对象的属性，甚至某些逻辑，才能够把这些对象的属性正确显示出来。
而我们知道Swing的UI组件都有自己的数据Model类。你必须把你的业务对象，放到UI组件的数据Model里面，才可以显示出来。你觉得这种方式比JSP差？

fastm的Template DOM也有自己的唯一数据Model，即ValueSet DOM。
同样你需要把你的业务对象放到Model，即ValueSet DOM里面，才能显示。
这种方式自然就和Swing很像。而不需要任何附加的工作。

要知道，现代Web Framework花了很大代价，做了很多工作，才模拟Swing，把页面组件和后端事件绑定起来。

能否Velocity关于日期格式化的代码？

其实，我并不关心日期格式化在vm里面做，还是在Java Code里做。
但大家却都很关心这个问题。和我讨论说，fastm的页面显示逻辑怎么能放在Java Code里面做呢？
所以，我也要关心一下。看看Velocity是如何完成这个神话 --- 在VM里面只做关于显示的工作。
请问，如果有这样的逻辑，如果 是负数，用红颜色显示，如果是正数，用蓝颜色显示。你认为这个逻辑是属于显示逻辑呢？还是业务逻辑呢？区分标准是什么？

fastm的目的就是返朴归真，倒退回到问题的起点 -- Servlet的问题。
那时候，没有fastm，只能在jsp上做文章。
但jsp的方向一开始就不一定正确，越走越远，越来越复杂。
Velocity也是这样，需要支持的脚本逻辑越来越多，越来越复杂。

fastm的目的不是为了修补这些误入歧途的技术。
而是完全走另外一条路，从根本上替代这些“复杂”技术。

关于“解藕”，你觉得在JSP，或VM里面写代码，反而是一种更好的“解藕”方式？
Swing也需要你把业务对象 填充到Swing UI组件专门的Model里面。这一点，fastm和Swing完全一样。
你觉得Swing的“解藕”很差？

还是MVC思维定势问题。

Swing也需要你把业务对象 填充到Swing UI组件专门的Model里面。
这一点，fastm和Swing完全一样。
你如果用Swing，你同样需要在Swing UI组件的Model里面自己控制分页，
设置Swing UI组件的显示风格。这些工作都是在Java里做的。
你觉得Swing的工作方式和结构很差？

用 Swing 的思路做 Web 开发有框架 Echo。这简直就是一种疯狂！我强烈反对这种开发方式，对于提高开发效率几乎没有任何实质上的帮助。
几年前我在用 Perl 做 CGI 时就是采用的这种页面模板替换的开发方式，如果继续走下去可能就和 fastm 很象了。确实是很朴素的思想，实现起来也不难。前几天和庄表伟讨论后认为：
1、Web 层开发重用和组件化并不是最终目的，而只是提高开发效率的手段。易用性也是非常重要的。
2、Web 层是经常变化的，评价各种框架优劣的标准应该是看其是否可以非常容易地应对这些变化。出现 MVC 就是为了解决以前把所有代码全部填入 JSP 所造成的难以应对变化的问题。我们把表示层开发完全前推到浏览器端，用 JS 开发了一整套可重用的控件（可以参考以前我发在 Web 表示层版上的一些帖子）。页面和显示逻辑放在一起是很适当的，我不认为页面完全不包含逻辑有什么必要。即使这样我把所有 JS 代码完全放在 JS 文件中，不是一样达到了页面完全不包含逻辑的目的？
3、一个好的 Web 层框架应该可以实现具有更好交互性的界面。fastm 如果不动态生成 JS，完全无法提供更好的交互，因为所有的工作还是要从服务器过一趟才能完成，完全没有考虑到浏览器端的计算能力（JS+DHTML）。以前我所说的基于 FORM 的请求/响应模式的所有问题都没有解决。