以下是我 2009 年 GSoC 项目的规范简报

简介

我将要工作的工作流扩展将支持核心内容组件，并有能力支持其他组件（内容类型）

文档工作流将被分解为一组“站点”，一个项目将按照特定的顺序从一个站点传递到另一个站点，直到达到其最终站点，之后将执行任意的操作，例如“发布文章”。

结构

核心

基于 MVC，核心将作为整个扩展的中心控制器，它由两部分组成
1. 一个传统组件
2. 核心插件：一个系统插件，用于捕获与内容保存相关的 J! 触发器，并将它们传递给“组件处理器”（见下文）

钩子处理器

将实现钩子以允许开发者在特定事件发生时执行任意操作，最初将实现一个钩子，该钩子将在从一站转移到下一站时调用。

字段处理器

它们处理“站点”字段的渲染和存储（例如，评论字段、文件附件等...）

组件处理器

所有特定于组件的代码都将放置在这里，这些处理器作为扩展与正在工作流的内容的组件（例如 com_content）之间的层。

每个处理器由两个文件组成

1. 一个包含处理器的元数据和其他参数的 XML 文件，其中包含了定义当处理器的类型项目被保存时触发的“J! 事件”名称的“onSaveItem 触发器名称”，文件还包含支持的“最终操作”列表，这些是项目到达最终目的地时可以执行的操作（例如发布、删除、存档等...）

2. 一个包含处理器实现的 PHP 文件，它必须实现以下方法（根据需要可能会更改）

• lockElement (id)
• unlockElement (id, gid)
• onItemEdit ()
• getItemRevision(id, rev)

关于 getItemRevision() 的更多内容
如果所讨论的组件（例如com_content）支持版本控制，该方法返回请求的版本；如果组件不支持，那么该方法将简单地忽略$rev参数，并返回数据库中存储的内容。

上述方法列表是初步的，并可能会随着开发进展而发生变化。
当工作流被保存时，组件的onSaveItem触发器会注册到核心插件中，以便当事件被触发时，核心插件捕获它并加载正确的组件处理器。

版本控制

在处理工作流时，内容可能会在达到最终形态之前被多次编辑，这引出了“版本化”的问题。这个扩展将不会处理工作流中内容的版本控制，但在内容管理的未来版本中可能会包含对版本控制的内部支持。
这种内部支持将通过“组件处理器”插件提供，它允许每个组件在支持版本控制时以自己的方式处理版本控制，如果不支持，则忽略它。

工作场景

管理员想要为特定类别的发布内容创建一个新的工作流。

管理员将使用后端屏幕来创建该工作流；他可以指定他想要工作流的类别/部分。

管理员定义了“站点”以及每个站点的自定义字段，并保存工作流。

用户xyz发布了一篇文章，onAfterSave事件被触发，核心插件捕获此事件并加载与内容类型对应的组件处理器（在这种情况下是com_content处理器）。

“com_content”的组件处理器为所有用户组锁定文章，并为站点2的ACL用户组解锁。

在两个站点之间的转换过程中，会调用一个钩子，调用所有已注册的处理器。这些处理器之一将向站点用户发送关于等待处理的项目的电子邮件。

站点2的用户登录J!并访问“待处理项目”视图（通过前端或后端均可访问），站点2填写分配给站点的自定义字段（评论和文件附件），并将文章传递给站点3。

核心为除站点3以外的所有人锁定文章，文章以类似方式继续，直到达到最终目的地，在那里将决定“最终操作”，支持的最终操作将依赖于“组件处理器”，对于com_content，我想不出除了“发布、删除、移动到类别/部分”以外的任何操作。

关于“视图”的说明

组件将具有几个视图，但没有什么异常的，除了允许管理员创建工作流的视图，这个视图将包含一些JavaScript魔法来提高可用性。