这段时间在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代码
因为逻辑嵌套只有两层,那么对应的fastm DOM也只有两层。
fastm DOM其实没有增加复杂度。而且,fastm DOM还简化了复杂度。
这是fastm的一个优点。
ValueSet DOM是fastm实现显示逻辑AOP和显示逻辑重用的关键结构。
也是Pipeline式处理过程的数据交换中枢。
不在这里讨论了。:-) 以后证明。
(5)fastm的代码长
其实,这个问题也有些误会。
只是“看起来”,fastm的代码比较长。
我本来是把fastm代码短作为一个优势来宣传的。
其它模板技术的代码分布在模板和Java Code两端。
即使不计算TagLib的代码。fastm代码其实还要比其它的模板技术短。
而且,fastm代码只存在于Java Code里,而且很多都是公用方法 -- 页面逻辑AOP。
不在这里讨论了。:-) 以后证明。
很多人鼓励我的精神,很多人耐心指正我的错误,也有很多人提出尖锐深刻的问题。最感谢的是,甚至有些朋友深入研究了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。
不在这里讨论了。:-) 以后证明。