代码擂台，特别有请buaawhl

另外补充一点，我的目的是希望 fastm成为一种 Server Template技术标准。
正在探索fastm在Portal方面的优势，正在跟踪当前的Portlet标准 (JSR128?)，所作的第一步工作。
希望做一个类似于JetSpeed, eXo, Liferay之类的Portal项目。

所以更关心服务端的数据结构。我的Java Script很差。
在界面端的操作性就没有用Java Script。

这个例子的目的在于挑战JSP, Tag LIb, Velocity, Tapestry的显示输出特性。
如何用JSP, Tag LIb, Velocity, Tapestry把这么复杂的数据结构输出到页面？

希望对fastm有所怀疑的朋友们加入这个代码擂台。以证明其它的模板方式比fastm更加直观优雅。

1 velocity-tools里面本身有一个DateTool干这个活，就是一个格式转换的函数，相当于一个用于格式化的helper类。至于这个函数怎么到application作用域里面去的，spring的文档说得很清楚。（不过我用的不是这个，hehe）
你不会认为只有在脚本里面编写的格式化宏才是真正的只用到了显示逻辑吧。
2 至于颜色显示，你有一个误解。负数和正数显示的关键是必须要用颜色区分，但并不限定要用哪一种颜色。你说这个是什么逻辑。model里面给出的东西只是数据而已，在财务的上下文中正数负数本身的语义不会因为所显示的颜色而有所变化。

至于我前面体的那个表中各行杂色显示，则更加单纯。不要以为这里只涉及到颜色显示，html中可能被定制的东西多着呢，难不成所有需要判断才能够下结论的东西都要放到fastm的java端代码中去（比如字体字号标题等等）？这类东西可能发生变化的情况要远大于model中的数据对象。还有关键的一点，即便按你所说得这么做是正常的，那么会有一个非常严重的不一致现象，或者一种臭味：有一些格式化的信息是在你的模板中的，另一些格式化信息则是你的"model"自带的。好好想一想开发哲学吧。
个人认为推介一个东西关键不在于它怎么的好，而在于它的限制是什么。fastm和jsp,velocity相比，开发思路上有很大的不同，只是一个喜好而已，不存在替代问题。而且fastm现在的情况，带来的麻烦会比收益要多。

其实在显示方面，我碰到最多的倒不是日期的输出，而是数字输出。一些人为了表格的美观，通常要求把小数中不必要的零都抹掉，还有一些切断规则等等。但不论怎样，model给出的数据都是真实的数据，在velocity中我只是调用一个格式化函数来干这个脏活。对于这类情形，fastm难道是在原来的model上面在构建一个只用于显示的、所有数字都用字符串表示的"显示model"?

至于我前面体的那个表中各行杂色显示，则更加单纯。不要以为这里只涉及到颜色显示，html中可能被定制的东西多着呢，难不成所有需要判断才能够下结论的东西都要放到fastm的java端代码中去（比如字体字号标题等等）？这类东西可能发生变化的情况要远大于model中的数据对象。

这个我还是坚持原来的意见。我认为把逻辑（任何逻辑）放在Java端，比放在页面端，可维护性，可重用性，要好很多。


说的没错。这是一个真知灼见。Thanks for the good point.
格式化的信息分布在 模板和 Model两端。确实是一种臭味。
是fastm带来的负面效应。

但这一点，我还是想和带有资源文件的桌面控件比一下。
你在资源文件里面定制了Layout，和基本组件。
你可以在程序里面改变这些组件的风格。
也许情况不完全一样，但这点真的无法容忍，真的是“非常严重的不一致现象？”

我的个人看法，觉得在把逻辑分开在页面端和Java Code里面才真的是“非常严重的不一致现象？”

这也许确实是开发偏好的问题。看需求而定，
格式化的信息分布在 模板和 Model两端。带来的维护成本高。
还是逻辑分开在页面端和Java Code里面。带来的维护成本高。

我所遇到的情况恰好是后者。页面逻辑非常复杂。动态要求很高。
所以，一直极力推荐fastm。

现在，我需要进一步确定了目标人群。
如果在你的应用中，
逻辑分开在页面端和Java Code里面。带来的维护成本高。
而格式化的信息分布在 模板和 Model两端，带来的维护成本不高。
那么fastm是很好的选择。

buaawhl,
fastm的想法很不错,但是在把所有和显示逻辑相关的代码都放在Java代码里面, 我是不能接受的.

拿你说的时间显示格式的问题来说, 如果用户说更改一下页面只显示到分钟,不用显示到秒,如果用fastm的话, 我需要改写java代码,重新编译,然后再重起服务器,看一下效果, 而用模板语言的话,我只要有个文本编辑器, 改写一下模板上的代码就好了. 你觉得哪个方便呢?

通常的应用系统我们是不能随意重起的, 如果只是为了修改页面上的显示逻辑,而需要重起服务的话, 我是不能接受的, 不知道fastm在这方面怎么处理?

我比较喜欢模板功能比较强大的模板语言, 如Freemarker (你可以认为它是Velocity的加强版本).
加上你举的例子的代码做说明:
关于时间格式的Java代码

Map content = new HashMap();;
content.put("date", new Date(););;

模板上的代码:

<td>Date: ${date?string("yyyy-MM-dd HH:mm:ss");}</td>

颜色的处理:

<#assign color = result > 0 ? "blue" : "red">
<font color="${color}">result</font>

另外一点我不习惯的是在fastm里面要求我用DOM方式准备好我的展示数据, 对比而言, 直接用现成的完整对象关系图来做处理更简单.举一个例子来说, 我有一个Person对象, 我想在页面上展现出来, 如果是支持完整的对象关系图, 在Java代码里面把它放入:

Map content = new HashMap();;
content.put("person", person);;

在页面上的显示就交给模板编写者了, 他们要怎么修改显示逻辑都不用动到Java文件,这样这部分的人员你可以找不用了解Java的人员来写,在项目成本上是一个优势:

<td>${person.name.firstName}</td>
<td>${person.name.lastName}</td>
<td>${person.address.street}</td>

thanks for the deep disscussion.

“我只是调用一个格式化函数来干这个脏活”
注意，这个格式化函数是Velocity支持的。
这种特性必须在脚本级别进行支持。如果脚本不支持，你没有别的办法，只能直接调用Java函数。
当这种需求越来越多，脚本需要支持的格式化函数就越来越多，就会越来越复杂。

fastm由于不支持逻辑，不会因为需求的增加而变化。不会变的复杂。
没有一个专门的函数文档供你参考。

“对于这类情形，fastm难道是在原来的model上面在构建一个只用于显示的、所有数字都用字符串表示的"显示model"?”

fastm的ValueSet DOM里面只放"显示model"。
ValueSet DOM不放，也没有办法放“业务数据Model”。
你需要在程序中把需要显示的内容格式化之后，放到ValueSet DOM里面。

你说的这种情况，fastm只能重新编译、重启。
如果在开发阶段，重启没有问题。
如果到了发布给用户阶段，才碰到需要改动显示逻辑，fastm确实没有办法。

据我所知，如果发布的产品遇到这种情况，
需要程序员重写代码，测试人员重新测试，用户重新接受发布。
不太可能出现就在用户的服务器上改个文件就可以了。

另外，如果你只需要改动静态风格和Layout的话，直接改动fastm模板（HTML，所见即所得）。fastm会自动更新模板。和JSP, Velocity一样。
动态显示逻辑，fastm就没有办法了。因为fastm模板就不支持逻辑。

确实，你给出的代码能够在 浏览器或 HTML编辑器里面正常显示，变量声明，计算，if, else, for不多的情况确实如此。
如果变量声明，计算，if, else, for很多，这个页面就不能在浏览器或 HTML编辑器里面正常显示。

fastm模板无论结构多么复杂，还是纯粹的HTML文件。

buaawhl:我觉得前面各位讲的问题都很有道理，你可以暂时当作不把自己当作fastm的作者重新看一下这些帖子

我的帖子和他们的意思基本上是一样的，其实你这个valueset的组装完全是多出来的，这个和struts的formbean差不多，但是不同的是你的fastm了解HTML的DOM结构，这带来两方面的问题：
1。展示媒介(HTML)和展示结构(DOM)完全分离，基于单责任的原则这当然是个好事情，但是本来在HTML编辑器里面还可以进行一定的所见即所得编辑，现在这个展示结构的valueset组装过程完全无法看到，就想我所说的，这是转移目标，因为你总要有一个地方解决文档结构的问题，fastm使它更难了，如Dlee和各位所言，还不如放到javascript里面去，至少不需要重新编辑，因为这里的关键是结构，所以java并没有多少优势
2。耦合的问题，实际上是界面HTML的变化必须要求你的valueset的变化，你这个地方很难说VALUESET是VIEW的view和VIEW的MODEL，因为你的view的view变化一定要求view的model变化，这违背了MVC的出发点：

一个model可以用多种不同角度的view使用，view的变化不影响model的变化

问题的关键是fastm模板的简单是以java端的复杂为代价的。你在那里搞一个显示用的DOM我觉得不爽但还可以接受。但是把html/css相关的标签也放到那棵树里面，那就有点@##!@#了。关键的问题是同样的标签，你一部分在模板中，一部分可能在java代码的显示控制部分，不显得有点荒谬？
fastm最好的情形下充其量也只是转移了复杂度，并没有简化。一般情况下反而是搞乱了。用velocity的好处是你在那里面能够做的显示控制有限，相对还易读一点，而用java代码来干这个事情，同样的事情可以做的方法至少在3倍以上。对于那种if/else/for很多的情形，用了fastm模板即便能够静态显示出来，也不是以所期望的方式显示。而java代码却是复杂了很多。
从我个人的看法，相对于mvc的标准做法，xmlhttp把v整个以及c的一部分迁到了客户端。而fastm则是试图把v的绝大部分迁到服务器端。前者的做法我非常赞同(虽然有些顾虑，也没有机会去实践)。但对于fastm的做法，就是说如果同样的数据我要有多种显示方式，必须在java端搞定多个显示用的dom，这个也太!!!!!了巴。
要知道，脚本的目的就是方便大家的生活。