关于template功能上的几个需求 about er HOT 13 CLOSED

另外，个人建议默认输出是HTML转义的，在必要时刻才使用$value|raw来取消HTML转义，以减少XSS出现的可能性

from er.

我个人感觉for, if这些功能还是放到业务逻辑里面去做比较靠谱，模板就应该简单一些，不要加入太多的语言特性。

另外，个人建议默认输出是HTML转义的，在必要时刻才使用$value|raw来取消HTML转义，以减少XSS出现的可能性

这个我是支持的。

from er.

模板要是 Mustache 风格的就好了，现在完全爱上这种写法了，极度简单明了！如果需要母版之类的支持，扩展几种符号也能完全搞定。

from er.

@mytharcher 我有考虑过写个Mustache的helper接esui，然后让er+esui可以用mustache，不过这最多会做为一个patch出来，ER本身依旧会用这一套模板，这是考虑业务线的工程师的熟悉性和掌握在 @errorrik 手里需求的可控性。

另外，Mustache有一个很有趣的问题，比如我知道我有10页的内容，现在要生成一个Pager。在不使用helper的情况下，Mustache因为没有for功能，所以搞不了这事，我的方法是在data中弄个数组[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]，然后用这个数组去生成Pager……

我提这个只是想说明，就算我们用Mustache，为了支持产品线的很多常见需求，也得再弄个helper bundle出来。

我还想推荐jade呢，不过esui本身的出发点就是无js情况下HTML基本可用，所以还是算了

from er.

Pager不就应该是组件考虑的事么。。。好像从来没在模板里写Pager。对于这类特殊需求，用管道过滤器的模式应该可以解决大部分，只不过可能有的方法会略恶心，比如数组索引从0开始，我要生成个1开始的序号。

当然我只是个建议，目前看来要迁移一种模板风格成本可能略大。

from er.

@leeight

我个人感觉for, if这些功能还是放到业务逻辑里面去做比较靠谱，模板就应该简单一些，不要加入太多的语言特性。

有不少人和我提过类似的想法，我说说我的出发点。

举一个简单的例子：

有一篇文章，要说明contributor，有一个数组的人名，要显示出来。

这是个很简单的需求，我们一开始决定用逗号分隔显示人名，在模板不支持for的情况下，我会这么做：

data.contributors = data.contributors.join(', ');
render(data);

既然模板没有for么，这事只能在Action层处理，那就这样，挺直观的。

然后，这个需求说变就变了（该死的PM），现在我们人名要显示为一个列表了，所以我得这样写代码：

var template = require('er/template');
// 模板内容就是`<li>${name}</li>`
var singleContributorTemplate = template.get('singleContributor');
var html = [];
for (var i = 0; i < data.contributors.length; i++) {
    // 很遗憾我们的template还没有format这种功能，得用其它库
    var item = require('tangram').format(template, data.contributors[i]);
    html.push(item);
}
render('<ul>' + html.join('\n') + '</ul>');

可以看到：

• 当展现方式变化时，我要改tpl和js逻辑
• js逻辑太多地关注 用什么标签 ， 生成什么结构 这样的事，再加上事件监听、逻辑处理等工作，js复杂而臃肿

因此，我支持模板实现for等功能，不过for里要不要带index可以讨论。

from er.

@mytharcher

认同你的观点，无论用Mustache还是jade还是ejs还是啥，我们总是有办法实现相同的功能，ER带的template说实话语法不怎么爽，希望不要被 @errorrik 打~不过反驳一个观点：

Pager不就应该是组件考虑的事么

ER和组件没有关系，使用ER做项目并没有 有Pager这么个组件 这样的前提，看 example/book-store 这个示例，ER支持很单纯的HTML+CSS+JS，在图书列表页我也演示了pager咋生成。

from er.

for 的index功能现在就是支持的。变量的支持我持保留态度。

默认html转义的功能fixed on 49ddbfb

这套模板设计时候最大的初衷就是写的时候能有语法高亮，所以就设计成特殊html注释来做了。从语法本身来说，就是一个很普通的模板语法，和爽实在差的太远，也没往那靠过。

确实，在能满足需求的前提下，Mustache是很爽的。

from er.

随便唠叨一下，和现在的ER无关。

其实我曾经一直在想，ER确实是需要提供一个默认的模板，但是不是要把模板变成可配置的，比如

// 事实上是需要adapter的
require('er/config').template = 'Mustache';

View中这么实现：

var config = require('./config');
require(
    [config.template || './template'],
    this.renderTemplate.bind(this)
);

不过考虑到这么一搞，不能用不带callback的require，整个流程挺难受。另一方面来说，现在的View都这么轻量了，几乎啥也没有，不想要ER的自带template的话可以自己去建个MustacheView基类，甚至不用继承ER的View，Action只要有render方法就当View用，根本不关心类型。

所以，这事也就没做了，在这里就是把当时的思考过程记录下，社区里或者内部哪个项目团队在这方面有想法不打算用这个弱暴了（真心的，别打我）的template实现的话，可以把这段话丢给他。

from er.

真要支持多种模板引擎的话，不如学学TJ大神在Express里engine的做法，专门搞了consolidation这个中间件来adapt。这样ER就不用关注模板怎么实现了，而原来的就当一套默认引擎附带就OK了。

只是没仔细看node下的consolidation是不是可以省点事改改那到前端来用。

from er.

@mytharcher Express的做法我参考过，唯一的问题是，node是CommonJS，而浏览器端是AMD，AMD只有静态的require(id)才可以分析并优化，如果id是个动态的变量之类的，又会额外加入一次异步，出问题丢掉CallStack等，感觉得不偿失，所以没干。

from er.

这套模板最开始的设计，是希望能够有一个写html的地方。当时的考虑是，逻辑相关的东西，我们有javascript，为什么要在模板里做。当然，设计得这么简单得原因，也是因为有性能的考虑。

所以，现在看来，这个模板要是和开源社区的模板比起来，确实是功能弱。我觉得，有空的时候可以搞一把，不过不是现在。其实现在也能满足90%以上的需求。

我一向对添加feature持谨慎态度。当时添加for和if已经让性能降低了一倍多，所以，一直也没往里面加功能。如果再＋，就要考虑预编译成function了，以及缓存模板merge结果等优化了。

from er.

暂时关掉本Issue，待template模块测试用例齐全了再开话题讨论功能上的增强~

from er.