带有标签模式的 Ember.js 页面

Question

我想在 issue/:id/edit 上显示一个复杂的表格路线。我可以显示我需要的所有内容的唯一方法是使用多个选项卡。请参阅包含的草图以使情况更清楚:



那么使用 Ember 框架执行此操作的“规范”方法是什么？

我的第一次尝试是这样的:

模式1:部分

所以所有数据都被加载并绑定(bind)到单个 tickets/:id/edit路由和 Controller 。我正在使用部分加载不同的选项卡。

这起初工作得很好。然而，随着应用程序的增长，单个 Controller 变得太小而无法处理所有事情。有几十个属性，没有明确说明哪些是常见的，哪些属于各个页面。因此，我决定需要某种方法将各个选项卡的逻辑拆分为它们自己的“事物”。

模式 2:路线

每个选项卡都有自己的路由和 Controller 。所有数据都加载到基础 /tickets/:id/edit路线，所有的 child 路线都从那里“借”他们需要的东西。

setupController: function (controller, models) {
    var ticket = this.modelFor("ticketEdit").ticket;
    controller.set("model", ticket );
}

来自其中一条子路线的示例

我已经实现了一半，我已经在努力解决问题了。我需要阻止人们访问裸露的 /edit路线。我需要防止页面导航出现在浏览器历史记录中。我需要调整我的面包屑和其他小部件。

我可以自己解决所有这些问题(这不是问题的重点)，但我不确定这是否值得。底线是，路线模式并不是我需要的理想选择。所以在我投入更多时间之前，我想我最好停下来想想是否有更好的模式。

我想到了两个候选人。

模式 3: View

所以我可以为每个选项卡创建一个单独的 View 。他们都会分享 TicketEditController ，但我可以用一些自定义的东西打包它们，这样我就可以减轻通用 Controller 的负载。

缺点:它使水浑浊。我需要显示的一些小部件本身就是 View ，并且可能希望从 Controller 实例化。当我开始在 View 中的 View 中添加 View 时，不确定这将如何扩展。

尽管如此，这似乎是迄今为止最合适的。但我错过了什么吗？是否值得放弃路由模式？

模式 4:组件

类似于 View 。技术上可行，但需要对许多假定它们可以直接访问共享 Controller 的小部件进行重大重构。但是这种方法有很大的好处吗？没有把握。

模式五:？？？

？？？

所以这就是你进来的地方。

您如何看待这些方法？

你用哪一个？

关于这些/每一个，我缺少哪些问题或好处？

你能找出“模式 5”，或者这些都是解决这个问题的可行方法吗？

Answer 1

我想至少把我的想法放在这里，因为你正在寻找反馈。

从确定的模式来看，我偏爱前两种。我认为不同之处在于标签的书签/导航。我希望能够派人通过 URL 编辑特定选项卡(所以我更喜欢 #2)，但听起来您的要求是保持传统的选项卡式行为(选项卡不是页面并返回按钮不会将您带到上一个选项卡)。所以，是的，你可以 manage the browser history但听起来您还需要处理其他部分(面包屑/小部件)，因此这取决于您权衡那里的成本。

半生不熟的混合想法

部分模式的主要缺点是单片 Controller 。我想知道您是否会感觉更好地创建 Controller 混合，明确每个选项卡的哪些属性。也许每个选项卡都是一个 mixin:

App.TicketEditController = Ember.ObjectController.extend(
  App.TicketEditGeneralTabMixin, 
  App.TicketEditTextTabMixin,
  ... {

  //common properties

});

杂项

你可以考虑 http://discuss.emberjs.com/作为另一个获得反馈的地方。

Code Review可能是另一个思考的地方。