显示逻辑AOP, 复杂页面逻辑Craker -- fastm. .....

这段时间在javaeye的关于fastm的讨论，令我受益良多。特此感谢大家。非常感谢。
很多人鼓励我的精神，很多人耐心指正我的错误，也有很多人提出尖锐深刻的问题。最感谢的是，甚至有些朋友深入研究了fastm，并提出了改进方案。
并且很多朋友也讨论了fastm之外的话题，令我的知识面开阔。

我这里把这几天针对fastm的一些尖锐深刻的问题列出来。并感谢大家对fastm的深入思考、详细讨论和尖锐抨击。

（1）格式化信息分布在Template DOM和ValueSet DOM两个地方
[quote="charon"]还有关键的一点，即便按你所说得这么做是正常的，那么会有一个非常严重的不一致现象，或者一种臭味：有一些格式化的信息是在你的模板中的，另一些格式化信息则是你的"model"自带的。好好想一想开发哲学吧。 [/quote]

这个问题最深刻尖锐，击中fastm的痛处。
如果需要动态改变风格，确实需要在ValueSet DOM中设置风格。
这个问题是fastm无法解决的，因为fastm模板中不包含逻辑。

下面是我的辩护：
这是把逻辑从模板中驱逐出去必须付出的代价。
比起逻辑代码分布在模板和Java Code两个地方，我觉得，格式化信息分布在Template DOM和ValueSet DOM两个地方，这个代价还是值得的。
这个问题就是见仁见智，各有千秋了。

并且，在代码中改变界面风格，这种方式在有界面资源的桌面程序中很常见。
资源文件中存放着基本的界面控件信息。程序可以动态地改变资源文件的显示风格。
所以，我觉得，“在代码中改变界面风格”，也不是完全不可接受的。

（2）fastm的所见即所得并不是绝对的。

我在论坛里翻了半天，也没有找到是哪个朋友提出的这个尖锐深刻的问题。Sorry。
当fastm需要选择显示不同的内容的时候，模板里面同样要包括两块内容。
这样你在浏览器中看的时候，可以看到两块内容。
而程序运行的时候，却只出现一块内容。

所以，fastm显示的所见即所得也不是绝对的。

（3）违反了MVC
这个问题也确实存在。
fastm不是不能支持MVC，只是支持了MVC之后，操作不够直接。
fastm只和Servlet Response打交道就够了。
Template DOM + ValueSet DOM = result --> Response.
（4）DOM的复杂性。

其实，这个问题有些误会。fastm的DOM不是HTML DOM。没有那么复杂。

页面逻辑的嵌套层次有多少，那么fastm DOM的层次深度就有多少。
比如，这样的JSP代码

<c:choose> 
  <c:when test="${copyMade}"> 
    here we add a line. 
    <h4><fmt:message key="copy.ok"/></h4> 
  </c:when> 
  <c:otherwise> 
     here we add a line too. 
    <h4><fmt:message key="copy.nok"/></h4> 
  </c:otherwise> 
</c:choose>

因为逻辑嵌套只有两层，那么对应的fastm DOM也只有两层。
fastm DOM其实没有增加复杂度。而且，fastm DOM还简化了复杂度。
这是fastm的一个优点。
ValueSet DOM是fastm实现显示逻辑AOP和显示逻辑重用的关键结构。
也是Pipeline式处理过程的数据交换中枢。

不在这里讨论了。:-) 以后证明。

（5）fastm的代码长

其实，这个问题也有些误会。
只是“看起来”，fastm的代码比较长。
我本来是把fastm代码短作为一个优势来宣传的。

其它模板技术的代码分布在模板和Java Code两端。
即使不计算TagLib的代码。fastm代码其实还要比其它的模板技术短。

而且，fastm代码只存在于Java Code里，而且很多都是公用方法 -- 页面逻辑AOP。

不在这里讨论了。:-) 以后证明。