0

作为将相当大/复杂的现有应用程序移植到 Ember 世界的尝试的一部分，我正在使用以下技术动态生成和编译命名的 Handlebars 模板，并将视图与它们相关联：

var template = Ember.Handlebars.compile("some handlebars stuff");
Ember.TEMPLATES["myTemplate"] = template;

var view = Ember.View.create({
  templateName: "myTemplate"
});

我想做的一件事是能够重新编译新的/不同的 Handlebars 模板标记，它会覆盖名为“myTemplate”的模板，并让该名称的视图可以访问它。

尝试这样做时，我得到了意想不到的结果-一些说明问题的小提琴：

First fiddle - 显示如果在命名模板内容更改后渲染视图之前等待会发生什么。

第二小提琴- 显示如果在命名模板内容更改后渲染视图之前没有延迟会发生什么。

引擎盖下显然有一些我不理解的魔法。任何人都可以对此有所了解吗？

更新：

我浏览了 Ember.View 和容器模块的源代码，并意识到我可以通过以跳过容器缓存查找的方式覆盖“模板”计算属性来解决第一小提琴中的问题。我在这里放了另一个小提琴来演示我找到的解决方案。

这似乎以我希望的方式工作 - 但是 - 感觉就像我可能正在与框架作斗争并以一种可能会在以后咬我的方式从容器中“脱钩”。有没有更好、更Ember-esque 的方式来完成我想要做的事情？我发现的黑客会破坏东西吗？

更新 2

我还发现也可以简单地调用

view2.get('container').reset();

在第一个小提琴中附加 view2 之前。看起来更干净/更安全，但它“合法”吗？我已经更新了第一小提琴来说明这一点。

4

2 回答 2

0

（在第二个小提琴中，两个视图都显示了第二个模板）

这是因为view1.appendTo($("#target"));只是安排了追加，实际的视图渲染直到运行循环结束才发生。在此之前，您已设置Ember.TEMPLATES["myTemplate"] = template2;

（在第一个小提琴中，两个视图都显示了第一个模板）

很确定这是因为 ember 容器缓存了模板 fx，但不是 100%。检查...

于 2013-03-25T04:06:58.180 回答
0

我要打电话给这个回答。正如我在第二条评论中提到的，我在我的项目中使用这个小提琴中显示的解决方案，沿着这些思路：

mYiew.get('container').reset();

这里有一些关于容器不打算用作 API 的讨论：https://github.com/emberjs/ember.js/commit/5becdc4467573f80a5c5dbb51d97c6b9239714a8，但似乎没有提到使用容器其他用例的视图。

此外，可以直接访问 View 的容器（在“.container”处）——这意味着开发人员并没有“很难”达到他们对应用程序的“.__ 容器 __”所拥有的方式。这可能暗示了他们打算如何使用它。

由于 View 能够随时清除其缓存在我看来并不是不合理或不好的做法，因此我正在使用上述解决方案......至少直到有人让我有更好的想法（或缓存 API）。

于 2013-03-27T23:55:04.240 回答