我想在 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 的小部件进行重大重构。但是这种方法有很大的好处吗?没有把握。
模式五:???
???
所以这就是你进来的地方。
最佳答案
我想至少把我的想法放在这里,因为你正在寻找反馈。
从确定的模式来看,我偏爱前两种。我认为不同之处在于标签的书签/导航。我希望能够派人通过 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可能是另一个思考的地方。
关于带有标签模式的 Ember.js 页面,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25970178/