取消编辑：NSUndoManager 或单独的 NSManagedObjectContext 进行编辑？
我有一个视图控制器，它管理始终以编辑模式显示的视图。该视图本质上是一个表格视图，类似于 Apple 联系人应用程序中的联系人详细信息。我的视图下的模型由一个 2 级对象图表示，该对象图由根实体（称为 R）组成 - 与子实体 C 具有一对多关系。现在，R 是一个大对象（它有 20 多个属性，全部可编辑但非强制）。默认情况下，R 有 n 个子对象（n 是可配置值），但可以在 中添加或删除子对象R 的集合通过我的编辑视图和 C 的属性也可以编辑。请注意，C 实体包含图像元数据的属性，因此在编辑时可能会拾取图像并与模型关联。
对 R 及其子项的编辑是通过主表视图表单以及我导航（来回）以收集所需信息的“辅助”视图来执行的，具体取决于案件。
我的问题是，在这种情况下，您将如何实现“取消所有编辑”，即我应该如何隔离所有编辑以轻松恢复到编辑之前的状态？将 NSUndoManager 与我的主 NSManagedObjectContext 一起使用？有单独的 NSManagedObjectContext 进行编辑吗？两者之间的权衡是什么？
我不关心重做。我正在寻找一种想法/解决方案，可以在编辑时使用的内存量与应用程序在编辑时中断时保存用户数据的能力之间取得平衡。
感谢您的所有想法。
I have a View Controller that manages a view which is always shown in editing mode. The view is essentially a table view similar to that of a contact's details in Apple's Contacts app. The model underneath my view is represented by a 2-level object graph comprised of a root entity - call it R - having a to-many relationship to a child entity C. Now, R is a large object (it has 20+ attributes, all editable but non-mandatory). By default, R has n children (n being a configurable value), but child objects can be added and removed to/from R's collection via my editing view and C's attributes can be edited as well. Note that C entities include attributes for image meta-data, so there may be images picked and associated with the model while editing.
Edits on R and its children are performed via the main table view form, as well as from "secondary" views to which I navigate (back and forth) in order to collect the required information, depending on the case.
My question is, how would you implement a "Cancel all edits" in this situation, i.e. how should I isolate all my edits to easily revert to the state prior to editing? Using a NSUndoManager with my main NSManagedObjectContext? Having a separate NSManagedObjectContext for editing? What would be the trade-offs for each?
I don't care for redo. I am looking for an idea/solution that would strike a balance between the amount of memory used while editing vs. the ability to save the user's data if the app is interrupted while editing.
Thank you for all your ideas.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议不要在两个不同视图中具有相同编辑功能的设计。每个视图应该代表数据模型的不同实体/类的对象，因此应该具有不同的编辑器和撤消管理。
联系人应用程序显示了这是如何完成的。您可以在主表视图中删除整个联系人，并在详细视图中删除单个联系人属性。当视图消失时，每个视图中的更改都会被提交。这样的设置不仅使撤消管理变得更加容易，而且使用户更容易准确地了解他们所做的更改。
如果您想坚持原来的设计，我建议保留主表视图的撤消堆栈，直到主表完全卸载，即不是在详细视图加载时。
I would advise against a design that has the same edit function in two different views. Each view should represent objects of an different entity/class of the data model and should therefore have different editors and undo management.
The contact app shows how this is done. You can delete an entire contact in the master tableview and individual contact attributes in detail view. The changes in each view are committed when the view disappears. Such a setup not only makes undo management much easier but makes it much easier for the user to understand exactly what changes they are making.
If you want to stick to your original design, I would suggest keeping the undo stack of the master tableview until the master unloads completely i.e. not when the detail view loads.
我在此处总结了
NSUndoManager要正确使用 Core Data，必须在子上下文中完成。由于子上下文为您提供了“取消所有编辑”功能，因此您不需要 NSUndoManager 。因此，每个可取消的视图控制器都应该在子上下文中完成其工作，这意味着，例如，控制器 A 将使用文档上下文的子级，如果它转至控制器 B，则将使用 A 上下文的子级（文档上下文的子级的子级）。如果用户按“保存”，则会保存上下文，并自动将更改传播到父级。如果用户按取消，上下文将被丢弃，从而忽略更改。唯一复杂的是 iPad 应用程序，其中 A 和 B 可能都可见，并且用户在 A 上按“保存”（但这可能只是糟糕的设计）。I concluded here that for
NSUndoManagerto work properly with Core Data, it must be done in a child context. Since a child context gives you "Cancel all edits" capability, you don't also needNSUndoManager. Therefore, every cancel-able View Controller should do its work in a child context This means, for example, controller A would use a child of the document's context, and if it segues to controller B, that would use a child of A's context (child of child of document context). If the users presses Save, the context is saved which automatically propagates the changes up to the parent. If the users presses Cancel, the context is discarded thereby ignoring the changes. The only complication is with an iPad app where A and B might both be visible and the user presses Save on A (but this is probably just bad design).