对fastm的一些看法

Thanks very much. Yes, this is a very clear and good way.
深受启发。:-) 我可以这么实现，扩展一个ContextInterceptor extends DefaultValueInterceptor implments IValueInterceptor.  重载其中的 getProperty方法。
如果BeanUtils.getProperty() is null, then get the value from the Context Map. 
调用的时候，template.toString(model,  new ContextInteceptor( contextMap) ); 就可以了。



如果是， true就显示，false就不显示。那么，很容易实现啊。也不用扩展标签。
但如果是，true就显示一种内容，false则显示另一种内容，这个就要引入if else 标签。从而就破坏了branch = key 的结构。

呵呵，我也在研究你的代码。
要注意bean.getProp方法返回就是null的情况，就是bean有这个属性的get方法，虽然是get到null还是应该打印这个空值，而不用再去context找了。



我有个更易实现的方案，也不会破坏分支：对dynamic标签多个not实现。
比如 dynamic not: name,如果name对应的obj为false或为null,则展示内容。否则，不展示。

还有为方便起见就是 dynamic: sub in subs,可先不用实现，dynamic:subs直接用subs作为key也未尝不可(好像php模版就是如此的)，而且保持对以前页面的兼容。如何

多谢你的深入研究，指出了我的很多盲点，受益非浅。
你说的那些，都可以在 IValueInterceptor的getProperty中实现。比如，not.name等，则执行"如果name对应的obj为false或为null,则展示内容。否则，不展示"。subs. 也应该可以同样处理。

PHPBB, JDynamiTe Template的Text资源块（BEGIN/END之间的部分）的使用方法，和fastm完全不同，是把 Text资源块 取出来在代码中使用。即取即用。所以，里面的变量都从最顶层引用。不存在fastm这样的问题。
即，PHPBB, JDynamiTe代码必须把Data和Template一块对一块的显式结合在一起。代码里面充满了多次Data 和 Template Block的匹配。一定要用到JDynamiTe的库。

fastm的做法是，必须事先构造一个独立的Object DOM。然后，和Template DOM一次匹配。所以，构造Object DOM的代码，和Template之间，表面上毫无联系，用不到fastm的库。只有到最后的一次匹配阶段，才用到fastm的库。

呵呵，不用谢的，我也是从自己开发方便角度出发来看问题的。哪天从fastm的使用中获益，那是该我谢你啊。:)

fastm出发点非常好，我希望它越来越完善，尽快的成熟起来，才能吸引更多开发者的青睐。真正从影响力上超越国外的一些模版语言。

我会继续保持对fastm的关注

to:goldrain

在2004-07-18，我提出的fastm plus方案:)

http://forum.iteye.com/viewtopic.php?t=6289

看看是不是和你对fastm的改进建议如出一辙？

赫赫,原来在很久很久以前...
就有人关注fastm了

我觉得页面标签还是要考虑方便好用,一看就知道干什么的,
同时也要考虑实现方便嘛,也不要考虑什么复杂布局都能支持,否则fastm将背离简洁原则.
fastm只要能解决多数常用布局和数据访问的问题就可以了.对少数情况,可以适度放到类中去做.我觉得fastm要在这两者之间找到一个平衡点.

最近还在思考fastm的标签怎么做最合理,已经有点想法了.大致是:
一个dynamic标签肯定不够,要区分对待单个对象和list对象;
if作为逻辑判断还是要加入,else不要支持,分支的实现我也有点想法了.
还有就是对valueset的改造,
还有就是pojo,map我觉得要附着在valueset上再展示;
等等...

有时间再贴出来大家讨论讨论...

多谢大家对fastm的关注。:-)

fastm的很多特性，都是由大家的建议驱动的。
这次，我又根据 goldrain的意见，加入了相应的context map, boolean 等的Interceptor。

我一直严守的阵地，就是“逻辑标签”这一块了。:-)

加入了context map是好事。感觉你的dynamic越来越复杂了，什么都支持，为什么不考虑增加几个标签呢，我看了JDynamiTe的匹配方式，那种做法是适合只要一个dynamic标签的，而且就需要一个name标记。

但我们现在是对map,pojo和valueset等类型直接进行数据匹配，我们究竟需要怎样的标签？难道还是一个dynamic解决一切？如果不解决就对其修修补补？对我们的组装java类修修补补？为什么拒绝增加其他标签？

我们究竟要模仿JDynamiTe的什么？我觉得JDynamicTe唯一需要我们模仿的是<!---->做标记的方式，不破坏html页面展示。而JDynamicTe的其他，包括dynamic标签，都不是我们需要的。因为两者对数据的访问匹配机制就根本不同。

换了汤也要换药。我们需要的是类似velocity或就是jstl的那套访问对象的方式。因为我们的html直接面对map,pojo和valueset。与velocity等语言不同的或者说更先进的是我们不用在页面进行数据和页面逻辑计算了，而且我们用注释做标签使页面更干净了。其实你最近加入的context map不也是为了支持这种层次对象的访问机制?

现在你的dynamic,几乎无所不包，list，单个对象，单个对象为null就不显示?如果再加入支持boolean，boolean true就显示，false就不显示？false为什么就等同于null的效果？你的dynamic将越来越难以理解，使用者也将不得不接受你的这套难以理解的dynamic规矩。

对这么简单的模版，没有了任何计算逻辑，使用者是不在乎多学几个标签的，没有分支的标签也不会影响布局。相反一个标签如果过于复杂，只会让人难以接受。现在的fastm必须至少支持三个分工完全不同的标签：list，单个对象(不管是否null都展示标签包含的内容),if(用于对分支的判断和boolean的判断)

请buaawhl三思

不用担心。我上面说的是，那些扩展的部分，context, boolean 等，全都在Interceptor里面。fastm本身的匹配规则不变。Dynamic 对应动态块，可能显示 0, 1, n 次，这个概念非常的清楚明了。
0, 1 可以对应分支的显示，0 -- n 可以表示循环。

而且从语法的角度来说，循环标签完全可以表示分支逻辑。

if(a == 0){
  print 0;
}

可以写成
for(; a==0; ){
  print 0;
  break;
}

while(a == 0){
  print 0;
  break;
}

而fastm的定义方式，根本不用这么麻烦，就可以很简洁的就可以用统一的方式，表达这些语法树的概念。并且fastm本身就不是定义语法树的，而是定义资源树。
BEGIN END 是为了把一个Text切割成不同的DOM层次和部分。而并不是为了表达某个逻辑语法。类似于XML DOM, 而不是类似于velocity/freemarker script。

fastm的Template DOM是可以象 XML DOM那样使用的。你可以很方便的用现成的Template DOM nodes 任意组装新的Template DOM。

如果支持了逻辑标签，就丧失了这个功能。因为无法用一种简单直观有效的方法组织一棵语法树。

一个设计原则是：
能用一种方法做到的事情，就不必用另外一种方法。而且现有的方法已经非常统一简单直观。概念一定要统一直观。

另一个设计原则是：
能够放到代码里面的逻辑，尽量放到代码里面，便于组织管理调试。放到Template里面的东西，没有任何重用和管理的可能。