3

使用 Backbone，我为模型创建了一个视图。我想为用户提供以下工作流程：a）最初，模型内容仅通过模板显示，并且有一个编辑按钮 b）如果用户单击编辑按钮，模型内容将以表单和可以通过单击保存按钮将其保存回模型。c1) 如果保存成功，我们将通过模板重新呈现新的模型内容并再次显示 c2) 如果有任何验证错误，则使用错误更新表单。

我想出了以下关于如何实现这一点的选项。但我不确定最佳实践。任何建议都非常受欢迎。

选项 1：2 个子视图（一个用于显示内容，一个用于编辑内容）在显示和编辑之间的任何切换时动态创建（然后删除）。

选项 2：2 个子视图（一个用于显示内容，一个用于编辑内容）在任何开关（如切换）上隐藏/取消隐藏

选项 3：2 个子视图（一个用于显示内容，一个用于编辑内容）分配给任何开关上的父元素。

选项 4：1 个视图以管理模型内容和 2 个模板（一个用于显示，一个用于编辑），它们在显示和编辑之间的任何切换时呈现。

从我的直觉来看，我显然更喜欢选项 4，因为它只需要一个可以处理所有逻辑的视图。但也许我已经在性能、事件处理、DOM 访问等方面监督了一些事情。因此，任何关于 4 个选项的优缺点的激烈争论都受到高度赞赏。你怎么看？

4

2 回答 2

2

我一直在做类似的事情，除了编辑按钮不是附加到整个模型，而是附加到可以“就地”编辑的各个属性。为此，我一直在使用主干表单，将要编辑的元素替换为主干表单，然后在提交表单后重新渲染它。这工作得很好。

在您的情况下，由于您正在一次编辑整个模型，因此实际上会更容易。当用户单击编辑按钮时，将视图替换为主干表单，并在提交时重新渲染带有错误或成功消息的模型视图。主干表单使在表单上显示错误消息变得非常容易。

于 2012-08-12T22:19:52.920 回答
2

我已经尝试过选项 3（2 个子视图）和选项 4（使用 2 个模板的 1 个视图）。

这是3的论据：

在主干js中的只读视图和编辑视图之间切换

这是一篇宣传 4 的文章，在“将联系人切换到编辑模式”下：

http://net.tutsplus.com/tutorials/javascript-ajax/build-a-contacts-manager-using-backbone-js-part-4/

我发现选项 3 更麻烦，因为现在您有 3 个视图使用相同的模型。它在 DOM 中提出了问题，因为现在嵌套在内部有一个用于父级的 el 和一个用于每个子级的 el。它也带来了封装问题，因为子视图应该真的从父视图继承，但是这对于 javascript 来说是困难的：

使用javascript继承访问父类成员？

我希望选项 3 更像是一个与 DOM 中的 el 相关联的抽象基类。然后查看和编辑可以继承它并在内部设置el，防止两个el的嵌套。但这打破了backbone.js 嵌套视图的方式：

交换/切换/交换backbone.js视图到位？

我第一次尝试时，选项 4“刚刚奏效”。如果 View.editing 为 true，则拥有一个可以渲染的 editTemplate 是微不足道的。在实践中，只读视图往往很小，根据定义，交互很少，它只会在编辑视图中增加几行。

4 的缺点是你用切换逻辑弄脏了你的视图。

4 的一个论点是它增加了重用代码和加强 DRY 的可能性。

4 的最后一个论点是，您可能在某个时刻有一个“丰富”的表单，它始终处于打开状态，并且您可能只想启用对特定表单元素的编辑。例如，一个联系人表单可能有一个内部的地址视图来处理它自己的更新。因此，查看/编辑在未来可能不会相互排斥。

我终于让自己选择了可行的方法（选项 4），因为这两个选项都在 html 文件中使用了两个模板。主干.js 的实现细节对最终用户来说并不重要。

我认为这一切都值得写一些冗长的文章来衡量每种方法的优缺点，并附上现实世界的例子。Backbone.js 还需要内置主干关系，可能还有 Backbone.ModelBinder，以及更好的 ._super 实现。如果其中一些概念更加充实，它将更容易实现选项 3 恕我直言。

但我很好奇其他人的想法，因为现在 3 或 4 都不是完美的，我想知道最佳实践是什么，因为表单处理是人们进入骨干网的主要原因之一.js 放在首位。

于 2013-01-25T20:25:06.360 回答