FreeMarker三宗罪！

sitemesh文档说效率很高的，消耗时间在20ms左右。不过我没有实际测试过，不过没有感觉使用sitemesh，速度降低。

20ms已经很多了，一个jsp运行一般也就10ms左右（如果不访问db，只访问cache的话）

sitemesh是需要在运行过程中解析html的，有些浪费资源。

tiles不用，但tiles配置太麻烦，也难看:(

另外当访问量增大的时候，sitemesh消耗的时间会直线上升

20ms还多？请问你平时打开sina首页需要多少ms？而且你写的JSP居然都不访问DB？只访问Cache？这样的JSP充其量就是猜猜数字的demo罢了。一旦访问数据库，瓶颈都在数据库端。

退一步来说，你的JSP打开需要10ms，现在用了sitemesh，打开需要30ms，你能感觉得到吗？

freemarker 还有一点觉得不大好，就是那些标记，比如if else之类的都会在可视化IDE中显示出来，比如dw中，这样有的时候页面仍然被撑破，还不如webwork的那些标签或struts的标签，让你看不见呢

大哥，20ms是服务器处理时间，不算往返的数据传输时间

我们的应用大部分时间是不访问db的，否则当用户量上来的时候，db就会拖死应用

sitemesh的处理时间平时感觉不到，当每天的访问量超过300w的时候就能感觉到了，毕竟占了服务器的处理时间的三分之一，而且我以前测试的时候发现当访问量到一定程度的时候，sitemesh的处理时间会接近1s

我有点疑惑，这么大的访问量，而且还是不访问db的页面，似乎早就应该用静态HTML了，干嘛还要用sitemesh一次次解析呢？

看了freemaker的三宗罪，倒是对freeMaker产生兴趣了。

我在一个项目中使用了sitemesh，最后的感觉不是很好。
首先，平心而论，sitemesh解决了90%的页面。但问题就出在剩下10%的特殊页面上，这些有着特殊显示风格的页面必须单独设定包装器，有些不是太通用的也得为其单独写一个。

其次，在团队开发时，很多人不知道sitemesh到底替自己的页面包装了些什么内容，经常搞的一头雾水。到最后才发现是decorator里设置的问题。而且，这个decorator文件被多人修改也很不好控制。

最后，sitemesh需要解析body标记（也许是我没搞清楚），我的一些只有frame标记的页面很容易就被弄得无法显示了。

最后总算挺着坚持了下去。
不过做第二个项目的时候，放弃了sitemesh的使用，改用hongliang说的

<#import "common.ftl" as c> 

<@c.html title="标题"> 
这里是文本内容 
</@c.html> 

的方法了。
把import变为auto以后，页面会更清爽些。

如果需要新的风格，可以再写一个macro，如果遇到很特殊的页面不用macro即可，用起来方便很多，也解决了团队开发的问题。

以上是一点实践的经验，可能有说得不对的地方，希望大家多多批评。

        

太棒叻！！！这个是我之前没有想到的。我对sitemesh的感觉也是和您一样，虽然80%的事情它能做的狠好，可是我们偏偏总是被那特殊的20%束缚。FreeMarker就比较自由灵活，而且用起来狠爽。坚决支持这种做法，我认为这是目前为止WEB页面表现层最好的实践方案之一

不过似乎auto import只能通过Configuration.addAutoImport()这个API来做？不能通过配置文件？

freemarker.properties 有一个 auto_import
看看文档就有说明，例如
auto_import=/WEB-INF/macros/common.ftl as m

sitemesh给你足够的自由，即使是10-20%的问题sitemeth也给你很多选择，就看你怎么用。你可以单独写decorator，或者就不用sitemesh渲染。sitemesh.xml文件中decorator-mappers没有好好去理解吧。就看com.opensymphony.module.sitemesh.mapper.PageDecoratorMapper，通过它的配置，你只需要在head元素中加上
<meta name="decorator" content="none">，sitemesh就不去渲染你的，这还是最简单的，你还可以通过meta做更多的事情，在freemarker中使用就是page.properties["meta.xxxx"]