撤消CubicWeb中的更改

许多桌面应用程序都为用户提供了撤销上次更改的可能性：这 撤消功能 现已集成到CubicWeb框架中。本文档将向您介绍 撤消功能 从最终用户和应用程序开发人员的角度来看。

但是，由于语义Web应用程序和普通桌面应用程序根本不是一回事，特别是在撤销方面，我们将首先介绍 what 是 撤消功能 现在。

什么 正在撤消 在CubicWeb应用程序中

什么是 撤消功能 在桌面应用程序的上下文中非常直观。但是，在语义Web应用程序的上下文中，它有点微妙。本节将介绍经典桌面和语义Web应用程序之间的一些主要区别，以便记住这些区别，以便准确地陈述 我们想要什么 .

概念交易

CubicWeb应用程序对 Entity-Relationship 模型，由模式描述。这样可以确保某些数据完整性属性。它还意味着所有或没有调用 交易 ，这样无论事务是否完全应用，数据完整性都会得到保留。 or 不适用。

因此，事务可以包含更多的操作，而不仅仅是用户主要目的直接需要的操作。例如，当用户 just 写入新的日志，基础 交易 持有多个 行动 如下图所示：

  • 由管理员于2012/02/17 15:18创建博客条目：Torotto

    1. 已创建日志：Torotto

    2. 添加的关系：Torotto由管理员所有

    3. 添加了关系：torototo撤销博客的博客条目

    4. 新增关系：国家草案（草案）中的Torotto

    5. 添加的关系：Torotto由管理员创建

由于事务的本质（全部或全部）不同，“不可撤销的东西”是事务，而不是操作！

交易中的公共和私人行为

实际上，在 交易 “创建的博客条目：Torotto”，其中两个 行动 据说是 公众的 其他的据说是 私有的 . 公共 这意味着公共行为（1和3）是由最终用户直接请求的；而 私有的 意味着其他操作（2、4、5）是在“引擎盖下”触发的，以满足用户操作的各种要求（确保完整性、安全性…）.

而且，由于相当多的操作可以由“简单”的最终用户请求触发，其中大多数最终用户并不（也不需要或希望）知道，只有所谓的公共操作才会出现 1 在可撤消事务的描述中。

  • 由管理员于2012/02/17 15:18创建博客条目：Torotto

    1. 已创建日志：Torotto

    2. 添加了关系：torototo撤销博客的博客条目

但是请注意，当事务被撤消时，公共和私有操作都将一起撤消。

（in）从属事务：简单情况

可以使用CubicWeb应用程序 同时 由不同的用户（而单个用户在给定的时间处理给定的Office文档），因此在CubicWeb案例中并不总是有单个历史时间线。此外，CubicWeb通过 权限 授予每个用户。这可能导致一些交易 not 在某些情况下是不可恢复的。

在简单的情况下，两个（非特权）用户Alice和Bob进行相对独立的更改：然后Alice和Bob都可以撤消其更改。但在某些情况下，爱丽丝和鲍勃的行为或其中一个的行为之间存在着明显的依赖关系。例如，假设：

  • 爱丽丝创建了一个博客，

  • 然后在里面发表了第一篇文章，

  • 然后鲍勃在同一个博客上发表了第二篇文章，

  • 最后，爱丽丝更新了它的帖子内容。

很明显，Alice可以撤销对内容的更改，Bob可以独立撤销他的帖子创建。但是Alice不能撤消她的后期创建，而她还没有首先撤消她的更改。很明显，鲍勃应该 not 有权撤消Alice的任何事务。

事务之间更复杂的依赖关系

但更令人惊讶的事情很快就会发生。回到前面的例子，Alice can 在Bob在博客中发表文章后，撤消博客的创建！但这是可能的，因为模式没有 要求 在博客上发表文章。会不会 的日志 关系是强制性的，那么Alice就不能撤消博客的创建，因为它会破坏Bob的文章的完整性约束。

当用户尝试撤消事务时，系统将检查以后的事务是否对将要撤消的事务具有显式依赖性。在这种情况下，系统甚至不会尝试撤消操作并通知用户。

如果未检测到此类依赖项，系统将尝试撤消操作，但可能会失败，通常是因为违反了完整性约束。在这种情况下，撤消操作完全是 3 后滚。

这个 撤消功能 对于CubicWeb最终用户

通过Web界面向最终用户展示撤销功能仍然是非常基本的，并且将朝着更大的可用性而改进。但它已经完全发挥了作用。目前有两种方法可以访问 撤消功能 只要它已在实例配置文件中用选项激活 undo-support=yes .

完成更改后立即通过 undo 邮件中的链接。这样可以立即撤消仓促的操作。例如，在验证了博客条目的创建之后 第二篇日志 我们收到以下消息，允许撤消创建。

消息中撤消链接的屏幕快照

我们可以随时访问 undo-history view 可从启动页访问。

可访问历史视图的启动菜单屏幕截图

此视图将提供对事务及其（公共）操作的检查。每个事务都提供自己的 undo 链接。将只显示用户有权查看和撤消的事务。

撤消历史记录主视图的屏幕快照

如果用户试图撤消一个无法撤消或撤消失败的事务，那么将显示一条消息来解释这种情况，并且不会留下部分撤消。

这一切都是为了撤销机制的最终用户：这确实很简单！现在，在下面的部分中，我们将介绍撤消机制的开发人员端。

这个 撤消功能 对于CubicWeb应用程序开发人员

一句警告：这一部分是为开发人员准备的，他们已经对CubicWeb下的内容有了一些了解。如果不是的话 yet 案例请参考CubicWeb文档http://docs.cubicWeb.org/。

概述

撤销机制的核心是 本地源 超出RQL。这就意味着 交易 和 行动 是 没有实体 .相反，它们是在SQL级别表示的，并通过 DB-API 存储库支持 连接 物体。

一旦 撤消功能 已在实例配置文件中用选项激活 undo-support=yes ，每个突变操作（参见 2) 将记录在一些特殊的SQL表及其关联事务中。交易由 TxUuid公司 通过这些功能 DB-API 处理它们。

在Web端，最后提交的事务 TxUuid公司 在请求的数据中被记住以允许IMedite撤消，而 undo-history view 依赖于 DB-API 列出可访问的事务。实际撤消操作由 UndoController 可从表单的URL访问 www.my.host/my/instance/undo?txuuid=...

知识库方面

请参阅文件 cubicweb/server/sources/native.py 和 cubicweb/transaction.py 有关详细信息。

撤消信息主要存储在三个SQL表中：

transactions

存储txuuid、用户id以及事务的日期和时间。其他两个引用了此表。

tx_entity_actions

存储实体操作的撤消信息。

tx_relation_actions

存储关系操作的撤消信息。

当撤销支持被激活时，将为数据存储库上的每个变化操作向这些表中添加条目，并在每次撤销事务时删除条目。

通过存储库的以下方法可以访问这些表 Connection 对象：

undoable_transactions

返回的列表 Transaction 根据指定的筛选器（如果有）可供用户访问的对象。

tx_info

返回A Transaction 来自A的对象 txuuid

undo_transaction

返回的列表 Action 给定对象 txuuid .

注意：默认情况下，它只返回 公众的 行动。

网络端

暴露于 撤消功能 最终用户通过Web界面依赖于 DB-API 以上介绍。这意味着 交易 和 行动 不是 实体 链接人 关系 通常的视图可以直接应用。

这就是为什么文件 cubicweb/web/views/undohistory.py 定义一些专用视图以访问撤消信息：

UndoHistoryView

这是一个 StartupView ，可从列出所有事务的实例主页访问。

UndoableTransactionView

此视图处理单个 Transaction 对象。

UndoableActionBaseView

这个（抽象）基类提供了私有方法来构建行为的显示，不管它们的性质如何。

Undoable[Add|Remove|Create|Delete|Update]ActionView

这些视图都继承自 UndoableActionBaseView 每个都处理一种特定的动作。

UndoableActionPredicate

此谓词用作 选择器 为操作选择适当的视图。

除了这条主线 undo-history view 一 txuuid 存储在请求的数据中 last_undoable_transaction 以允许立即撤消一个仓促验证的操作。这是处理 cubicweb/web/application.py 在 main_publish 和 add_undo_link_to_msg 分别存储和显示的方法。

一旦可以访问撤消信息，通常通过 txuuid 在一个 undo 实际的撤消操作可以由 UndoController 定义在 cubicweb/web/views/basecontrollers.py .此控制器基本上提取 txuuid 然后调用 undo_transaction 如果出现撤消特定错误，则让顶级发布者将其作为验证错误处理。

结论

撤消机制依赖于对存储库上变化操作的低级记录。这些记录可以通过添加到 DB-API 并通过消息框中的即时撤销链接，通过的整个历史视图向最终用户公开。

撤销功能是功能性的，但是界面和配置选项仍然相当少。一个主要的改进是能够过滤出一种更细的颗粒，即人们希望看到的交易或行为。 undo-history view .另一个关键的改进是只对实体关系模式的一部分启用撤消功能，以避免存储太多无用的数据，并减少底层开销。

但这两种功能都与强大的设计选择有关，而不是将事务和动作表示为实体和关系。这在安全性和概念简单性方面有巨大的好处，但会妨碍使用许多方便的CubicWeb功能，如 小面 访问撤消信息。

在进一步开发撤销功能或最终修改这个设计选择之前，似乎强烈需要一些经验的回归。因此，请不要犹豫尝试应用程序中的“撤消”功能，并向我们发送一些反馈。

笔记

1

可以改进最终用户的Web界面，使用户能够选择是否希望看到私人操作。

2

只有五种基本操作（不仅仅是访问数据进行读取）：

  • C ：创建实体

  • D ：删除实体

  • U ：更新实体属性

  • A ：添加关系

  • R ：删除关系

3

意味着事务中的任何操作都不会被撤消。根据应用程序的不同，启用 部分的 撤消。也就是说，如果不阻止撤消事务中的其他操作（只要它不破坏模式完整性），则某些操作无法撤消。这不是后端禁止的，而是前端故意不支持的（至少目前是这样）。