有请charon，关于freemarker,fastm,fastm plus

你推荐的freemarker，我快速的浏览了一下。很有意思，但是我不会加入他们的开发组。因为我要说是对freemarker有什么想法的话，那就是给他做减法，而不是做加法。

这个问题，我要从版本谈起，你有没有想过，几乎所有的软件版本，都在不断的升级呢？不断的增加新的特性，不断的支持更多的东西等等。这样有什么问题吗？

而我的设想就是，如果一个设计是完整的，那么他的核心应该是稳定的，而他的外围的变化，任凭他怎么变，都不能叫升级。

我对与fastm的扩展，不是通常的“每天进步一点点”的扩展。而是有一个通盘的考虑，等我全部写完，这个设计也就到此结束，不再会有任何扩展了。

ok，回到问题本身，为什么我会想对freemarker做减法？因为freemarker的发展是在类似于“fastm”的基础上进行的，而不是在“fastm plus”的基础上进行的。区别在于，“fastm”与“freemarker”一样，只有两个概念：
Template + data model = output

因此，当面对实际的复杂情况是，freemarker的思路，就是使得Freemarker Template language越来越Powerful。但是这样的强大，并不见得就是进步，因为当FTL复杂到像一门真正的语言时，它与JSP，Velocity之类的实现就没什么区别了。而fastm的思路，则是，打死也不去动template，这样的结果，就是需要编写非常复杂的ValueSet组装程序，不但复杂，而且混杂了页面显示的逻辑，既不优雅，也不方便。

因此，我才提出了“fastm plus”，Template+ValueSet+ViewLogic=output

区别在于，template的作用就是显示ValueSet的数据，基于这样的目的而定义的模板的语法，只可能是一个有限集合，而不会“日长夜大”——“日趋复杂”。原始的ValueSet的内容，就是业务逻辑层的正常输出，不需要考虑到页面显示的内容，更不需要考虑页面显示的方式。而最终实现各种复杂需求的，是ViewLogic，这是模板与业务数据之间的桥梁。

一个框架设计出来，不但要能够实现目标领域内各种需求，更重要的是规划出一种具有一定限制性的模式，这样的限制性，不但是在于代码的限制性，更重要的是在于思维模式的限制性。在某一个框架下开放应用，就是按照这个框架的思维模式进行思考。有了这样的思维模式的设计之后，分工才变得有价值，或者说，实质性的分工在可能出现。

所谓实质性的分工与一般的分工的区别，就在于这样的分工，在承担不同工作的人员之间，有没有非常清晰的交接界面，还是只不过是工作量的划分，人员之间都必须不断的深入别人的工作。

我对ValueSet的定义，与FreeMarker和fastm都不同，我更加清楚的区分了ValueObject和ValueList。同时，在template定义中，只引入按名称选择、简单循环、函数调用三个概念，目的就是为了让Web Building人员，都能使用它。不会为之困惑，不会经常拿着模板页面再去问程序员。因为这样的设置，使得模板编写，远离编程的范畴。

而我对原始ValueSet的界定，是业务逻辑的输出结果，这就使得业务逻辑的开发人员，能够独立的，并行的开始工作。而不会被页面的不断变化所困扰。当然，也就不会经常被页面开发人员打扰。

最后，显示逻辑的复杂部分，都被集中到ViewLogic层，但是这一层的代码，都是单纯的ValueSet输入、ValueSet输出模式。因此，JUnit的测试，TDD的模式可以发挥作用。因此变得可以控制。

这样的框架，就不仅仅是一个技术实现的框架，更重要的，是包含了我对于Web应用开放模式的思考与选择，所以如果你仅仅是比较三者的功能强弱，那就会误解我的本意的。因为我一旦实现了这些设计，也就不会再打算去“升级”它了。

这篇文章我本来打算等fastm plus的demo全部写完之后再写的，但是看到你似乎有结束讨论的意向，我想想还是先说出来比较好。你看看有没有道理？

同意viewlogic层的想法

不知我理解是否有误，fastm从一开始我感觉在valueset和template间应有一层，不过后来感觉实际上valueset就是viewlogic。

我和buaawhl的相同之处在于，都同意ValueSet可以被多次处理。但是我和他的区别在于，ValueSet的后续的处理，由谁来调用，而我认为应该是由template层调用的。至于buaawhl，则没有明确的表述过这个问题。

能不能详细描述一下Template、ValueSet、ViewLogic的具体内容，表示层的逻辑相当复杂，如果只是分为三层的话，偶合度还是高了点，建议再细化，将组织结构、逻辑控制等抽离出来成为独立的概念实体。

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

这是另一篇帖子，里面有些demo。

ViewLogic是一层，在这一层里，可以写一个Class，也可以更加复杂，这没有限定。

是这样的。ValueSet就是由View Logic创建的。

庄表伟希望把这个ViewLogic单独分离出来。这样用户就不用和ValueSet直接打交道了。

上篇回贴把你的名字打错了，抱歉一个。

又考虑了一下，这个 viewlogic 层次的技术选择需要认真考虑。

如果以 javaclass 的方式，功能肯定是足够强大了，也可以 unittest 但是，和 fastm 包含 viewlogic 代码的方式一样，会有重新编译和发布的问题。而且，作为另一个与 template 分离，但逻辑上高度耦合的文件，在简单和维护性上是有额外开销的。

如果以 config/script 文件方式，也许可以很好的解决重新编译和发布问题，但，和上面一样，因为文件的分离与逻辑的耦合，简单和维护上也是有损失的。

如果试图避免由于分离文件所导致的设计损失，似乎放置 viewlogic 最合适的地方就是 template 本身，但，这岂不又违背了“keep template simple”的原则，走到现有技术的老路上去了？

暂时还想不出有什么两全其美的好办法。

freemarker的复杂的原因是为了对付那些20%的需求。实际上大部分的需求都可以用最常用的那些元素实现。
至于valueset，我想提一个问题。如果model给出的本来就是一颗业务数据的dom，就像freemarker的那个文档中的一样。那么，本质上来说就不应该为了显示再去构造这个valueset,否则就会有很大的重合。
那样，你就希望用脚本来起到一个封装显示逻辑的作用，于是就会出现另一个两难的问题。这个前面的jacky就分析得很清楚了。
freemarker和现在的fastm的区别就是，如果fastm为了避免if/else来构造一颗复杂的显示逻辑相关的valueset，那么freemarker也可以用这个valueset，从而同样避免了if/else. 但它给了人们另一个选择，就是在模板中搞定显示逻辑。

to:charon

一个框架之所以能够提高效率，就是在于“减少了可能的选择”。



看来你没有完全理解我的这段话的含义。既能这样做，又能那样做，不见得就是“强大”。

至于jackyz的问题，我是这样想的：
ViewLogic层如何实现，的确有一个取舍的问题，但是我们要看到我们是在哪些利弊之间做取舍。

1、如果只有一个jsp文件，代码都写在里面，自然不存在“重新编译和发布的问题”。
2、如果一次页面由多个文件协作完成，总会存在或多或少的耦合，关键在于耦合的“合理性”。也就是说，如果存在的耦合是“理所当然”的，那么维护失误就会减少。而如果耦合中有很多类似于“魔法数”之类的约定，那么维护就会遇到陷阱。
3、Config与Script是两个概念，前者没有执行逻辑，因此也就不需要编程的思考能力，而后者却需要这样的能力。因此我们在设计框架与分工模式时，就需要考虑这样的区别。