12

Ember.jsStateManager中的 还没有很好的文档记录，所以我对它的使用有一些疑问。

  1. 是否应该努力.goToState只从状态管理器内部调用？
  2. 我有时会发现自己在视图的状态管理器中镜像方法，例如save: -> StateManager.send("save"). 这有意义还是我错过了什么？
  3. 模型的所有修改（通常）都应该通过状态管理器吗？
  4. 如果一个视图具有不同的状态，是否应该使用ViewState带有子状态的模型进行建模，还是应该使用计算属性和视图属性仅在视图中保存该信息（状态管理器不知道视图的内部状态）？*

*一个示例可以是三步表单，其中所有状态都使用相同的模板，但在三个步骤中显示/隐藏了不同的区域。

Github 参考：https ://github.com/emberjs/ember.js/tree/master/packages/ember-states/lib

4

2 回答 2

6

关于您的第2点：

我有时会发现自己在视图的状态管理器中镜像方法，例如save: -> StateManager.send("save"). 这有意义还是我错过了什么？

您可以action在 Handlebars 模板中使用帮助程序并将 StateManager 设置为target

{{action "send" target="App.stateManager"}}

并且该send事件被发送到您的App.stateManager.

于 2012-03-29T14:08:06.733 回答
6

是否应该努力仅从状态管理器中调用 .goToState ？

大概。我不确定这一点，但在我看来，因为状态管理器知道你处于什么状态，所以它是强制执行合法状态转换的地方。如果您从状态管理器外部调用 .goToState，那么您在执行此操作时并不真正知道自己处于什么状态，虽然有时这还可以（也许这是您真正可以从任何其他状态达到的状态），但这不是一个好习惯将在。

我有时会发现自己在视图的状态管理器中镜像方法，例如保存：-> StateManager.send("save")。这有意义还是我错过了什么？

我喜欢 pangratz 对此的看法。

模型的所有修改（通常）都应该通过状态管理器吗？

我使用状态图的方式，不。我见过一些人使用状态图作为控制器层的完全替代品，但是，如果这就是你的工作方式，那么是的，它应该通过状态管理器。该模式是为了避免从视图直接操作模型；无论是控制器层还是介于两者之间的状态管理器对我来说似乎都是一个有争议的问题。

然而，我使用状态图的方式是使用状态管理器来管理应用程序的状态。如果修改会改变应用程序的状态（例如，如果在更新完成时有进度指示器），它可以扮演修改模型的流量管理器，但在我看来，模型更新不是其任务的一部分；它们属于控制器。

如果一个视图具有不同的状态，是否应该使用具有子状态的 ViewState 对其进行建模，还是应该使用计算属性和视图属性仅在视图中保存该信息（状态管理器不知道视图内部状态）？

我认为状态管理器需要知道（或应该知道）视图的内部状态。

出于好奇，您是来自 Web 开发背景，还是桌面/移动应用程序开发背景？我来自网络开发，状态图对我来说是一个新概念。我发现阅读David Harel的规范状态图论文（'ware PDF！）非常有用。对于一篇学术论文来说，它的可读性令人惊讶，并列出了自 2010 年底以来大多数 SproutCore/Ember 世界一直在使用的基本状态图概念（即这是Michael Cohen在编写 Ki 时所想到的。）

于 2012-04-05T19:43:12.437 回答