FreeMarker和Jsp的应用范围

之前我的答复中也提到过了，既然是模板，那么肯定应用范围就是通过模板生成一段文本。

这段文本，可以输出到UI中，那么就是做UI了，可是直接用，而可以类似Struts2一样用FM实现Tag。

这段文本，可能就是Java代码，那么估计就是用FM生成java代码了。

周围还有人用FM生成XML，不过不太看好这个，不是强项，XML的工具太多了。

再比如就是邮件模板啊，等等有简单逻辑的替换了。

如果说CSS的选择器和JQuery的选择器一定程度解耦了HTML和CSS，JS，我觉得没问题。FreeMarker和JS和CSS有啥关系？它是执行在服务器端的，咋分离JS和CSS？

这么说没问题，但是“可以做”和“适合做”不能同等。

FreeMarker对于文档生成来说适合，但是对于Web开发呢？我们从网上看到的FreeMarker的教程还有大家写的例子，绝大多数是用FreeMarker替代JSP做Web开发，但是这样能带来什么好处呢？逻辑清晰？后期维护成本降低？还是说仅仅是因为这么做比较“in”...。我只想用它去做我认为它能做好的事。

引用agile web development with rails里一句话，页面里不能嵌入代码？那是教条主义的做法。
我不觉得嵌入代码有什么问题，如果这个程序员算得上是个程序员的话，这个度很好把握

那么页面嵌入代码的好处是什么？

保持controller的纯洁。
我不相信有谁能完全把页面剥得没有逻辑。
比如假如我要输出一个客户列表，假如这个客户是90后，需要输出非主流
你把逻辑写在controller里？从hibernate拿到客户List，你再遍历这个List，遇到90后，在客户的某个域里写上非主流？
那你这个客户的Model是不是不纯粹了？多了一个字段叫 是否非主流？还多遍历了一次List
这种逻辑是不是只能在视图层面上做？
这个例子很简单，但是以此类推，肯定会有逻辑在视图上做。
不是所有的逻辑都放在controller里才是好的

这种需求和把20091120显示为2009年11月20日有本质区别吗？
如果你的需求变成：把中文变成拼音显示。你觉得应该怎么样实现呢？

html是markup lang，
template engine很适合这种markup lang——jsp当然也可以容易生成这些——但是

1.定位不一样的，jsp是server page，要有server code的，虽然现在更多是view角色，但它很轻易就做到独大了，我觉得这是越权。

2.scripty，fm对象属性、方法访问比较简洁，语法也简单，让一个美工来读规范的fm和jsp代码，一般fm更容易理解。groovy有gsp，但他们（和jsp）都把page中的dyn code（java、groovy代码）放在第一位，html tag放在此为（个人感觉），而fm始终是html html（做web时候）——因为我就是用来生成html的么，比较下macro和taglib的设计思想就知道了。

3.性能上，fm缓存一下很方便的，延迟refresh load，生成后的html的cache直接就在配置里配就好了，jsp好像要第三方做才可以。

4.还是macro，jsp的include static / dyn实现方式，可重用性不如macro高。

5.个人喜欢——java么，你就管好server端的事儿，要想多管的前端的，就弄个web bean，整一套东东过来（jsf貌似要这么做，zk也做得不错），gwt/dwr等更event-driven dev的方式不太感冒，但是真整一套过来，灵活性就不好说了（我正在为努力适应web dynpro而努力，优点体会）——还是喜欢markup + js这种（svg > flash flex > **activex，在我眼中）简洁明了的关系和开发模式。

6.熟悉fm的继续补充，说错了地方大家拍砖指正

把中文变成拼音显示的问题，我也插一句。看怎么考虑这个问题，我认为在哪里解决都是合理的，可以认为这是一个显示逻辑，数据我给出来了，页面怎么显示是页面的事情。你也可以说，我就要要一个拼音，你需要直接给我结果。
扩展一下，也许按照老外的习惯，把名放到前面呢，都推给后台处理，没有太大的必要。

如同上面那个问题，一个Date给出来，在zh_CN 下应该是2009-11-20,在en_US 下应该是 11/20/09 ，这个也可以理解为页面的显示逻辑。

关键有些时候在JSP上想动些小手脚，还是比较方便的。什么都弄到Controller里，确实没有必要啊。

软件以用为本，以实用简洁易维护为原则，只要不是故意违反，没有那么多限制吧。

用JSP2.0 + tagfile ，也是很好的方案，我认为也不比Freemarker差到哪里去，用过的人都应该很清楚，我考虑用FM生成的东西更好打包管理容易，更方便其他项目重用。

这位兄弟说的有一定道理。为什么大家会对V层的“干净”如此苛求，而忽略C的感受。我觉得原因有两个：
1、V层代码历来不好看，达不到Java程序员所追求的优雅。
2、MVC结构中，人们对M和V的认识相对清晰，C相对模糊。

M和V，边界清晰。C除了前后台交互控制，数据转换，还应该做什么？为了追求V的“干净”，就把原本是V的事情推给C，然后宣称天下太平，维护性提升。有一天当C变得臃肿起来之后呢？要知道这种情况下C里背下的V层的代码不结合V来看很大程度上是不可理解的。

更何况很多原本就是V中的逻辑，因为要强迫搬出去很可能产生大量额外，纯技术逻辑的代码。这种代码是可读性最差的。维护成本怎么降低呢？