主干模型视图：在编辑（通过表单）和显示之间切换

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

这是 3 的论据：

Switching between readonly view and edit view in backbone js

还有一篇文章在“将联系人切换到编辑模式”下宣传 4：

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

---

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

Access parent class member with javascript inheritance?

我希望选项 3 更像是绑定到 DOM 中的 el 的抽象基类。然后view和edit可以继承它并在内部设置el，防止两个el嵌套。但这打破了backbone.js 嵌套视图的方式：

Swap/switch/exchange backbone.js views in place?

---

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

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

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

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

---

我最终决定选择可行的方法（选项 4），因为这两个选项都使用了 html 文件中的两个模板。对最终用户而言，backbone.js 的实现细节并不重要。

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

但我很好奇其他人的想法，因为现在 3 或 4 都不是完美的，我想知道对此的最佳做法是什么，因为表单处理是人们使用表单的主要原因之一首先进入backbone.js。