EZ Publish/EZ Publish内容管理(二)
|
EZ Publish | EZ Publish安装与卸载 | EZ Publish的使用 | EZ Publish常见问题 | EZ Publish其他 |
内容节点[ ]
系统开始运作后，新的内容对象可以被即时创建。例如：当撰写一篇新闻文章时，一个新的文章对象会被相应创建。显然，内容对象本身不能漂浮在空间中，他们必须以某种方式组织起来。这时就需要节点和节点树。内容节点只是对内容对象的封装。在eZ Publish 中，每个对象可以由一个或多个几点表示。
下图演示了内容节点和它对应的内容对象（被节点引用）在系统内部的实现。
内容节点树有节点构成。节点是对象在节点树中的位置。节点树用来以树状结构组织系统中的对象。
节点结构
内容节点由以下元素构成：
. 节点ID
. 父节点ID
. 对象ID
. 排序方法
. 排序顺序
. 优先级
节点ID
每个节点有一个唯一的数字ID。系统用这个ID 来组织与保管不同的节点。这些ID 不能循环使用。换言之，如果某个节点被删除，这个节点的ID 不能被其他节点重用。 父节点节点的父节点ID 为节点树中父节点的节点ID。
对象ID
系统中的每个对象有一个唯一的数字ID。节点的对象ID 为这个节点封装的对象的ID。
排序方法
排序方法定义如何排列节点的子节点。以下排序方法可用：
| 数据类型 | ID | 描述 |
| 类标识符 | 6 | 节点按照对象的类标识符排序 |
| 类名 | 7 | 节点按照对象的类名排序 |
| 深度 | 5 | 节点按照它们在树中的深度排序。根节点的深度为１，每下降一层，深度加１ |
| 修改时间 | 3 | 节点按照对象的修改时间排序 |
| 子节点修改时间 | 10 | 节点按照它们子节点的修改时间排序 |
| 名称 | 9 | 节点按照对象名排序 |
| 路径 | 1 | 节点按照它们的路径排序 |
| 优先级 | 8 | 节点按照它们的优先级排序。每个节点有一个优先级字段，用户可以在这个字段输入优先级。这种方法允许节点按照用户的要求排序。优先级字段在稍后解释 |
| 发布时间 | 2 | 节点按照对象的当前/发布版本的发布时间排序 |
| 分区 | 4 | 分区4 节点按照对象的分区ID排序 |
注意：可以把多种排序方法组合使用来实现复杂排序。但是，因为节点无法“记住”组合（只能对每个节点指定一种排序方法和排序顺序），必须在模板中实现复杂排序。
排序顺序
排序顺序决定排序的顺序。两种顺序可用：
- 降序(0/FALSE)
- 升序(1/TRUE)
例如：如果排序方法为“名称”并且排序顺序为“升序”，子节点会按照字符表顺序从A 到Z 排列。如果排序顺序为“降序”，子节点会按照字符表顺序从Z 到A 排列。
优先级
优先级字段允许用户为节点指派正整数，负整数和0 为优先级。用这个字段可以按照用户的要求对节点排序。如果排序方法为“优先级”，子节点将会按照它们的优先级排列。
内容节点树[ ]
节点树是对象的树状结构。每个叶子是一个节点（也被称为位置）。每个节点引用一个对象。一般情况下一个对象被一个节点引用。因为节点封装了对象，任何类型的内容对象可以被放置在任何位置。节点树至少包含一个节点，称为根节点。根节点的ID 为１。根节点是一个虚拟节点，它不封装任何真实对象。直接位于根节点下方的节点称为顶极节点（顶极节点在下一章解释）。理论上，节点树的深度和广度没有限制。下图演示了对象如何被节点引用，并共同构成节点树。
下图演示了同样节点结构的外部视图。
多位置
同一个对象可以被多个节点引用，这意味着同一个对象可以出现在节点树中的不同位置。这个特性可以用来例如：将某一篇新闻文章放置在两个位置：首页和归档页面。当使用多节点/位置时，只有一个节点可以作为对象的主节点。主节点通常代表对象在节点树中的原始位置。如果对象只被一个节点引用，那么当然这个节点就是主节点。主节点被用作避免重复的检索结果，无限递归循环，智能过滤等用途。下图演示了一个对象有多个位置的节点结构。
下图演示了相同结构的外部视图。
易犯的错误
在计划内容结构时，一个很容易犯的错误是把多位置想象成为文件系统中的快捷方式/链接。不幸的是，节点树并不是这样工作的。当为对象添加新位置时，eZ Publish 不会遍历并为对象原始位置的子节点添加位置。例如：如果一个文件夹包含若干子文件夹，子文件夹包含文章，图像等等。当为这个文件夹指派第二个位置时，它的子文件夹和子文件夹不会自动出现在文件夹的新位置下。
附加说明
只有发布的对象会出现在节点树中。新创建的对象（草稿）在第一次发布前没有被指派的节点。只有所有引用某个对象的节点都被从节点树移除，才能说这个对象被移除（状态设置为归档）。被移除的对象会出现在回收站。需要牢记，eZ Publish 的回收站是只用扁平结构。这与操作系统中的回收站不同。回收站中的对象可以被恢复到原始位置，但是只有在它们的原始位置的父节点没有被删除时才可行。否则，用户必须在恢复过程中手动为其指定一个备选的/新的位置。
注意：无论对象的原始父节点是否仍然存在，用户都可以为其手动指定恢复的位置。
此外，如果一个包含新闻文章的文件夹被移除，文件夹和文章都会在回收站中以同一级别显示。只恢复文件夹不会自动恢复文件夹下的文章，因为当移除节点时，文件夹和文章之间的关联已经丢失。这种情况下，需要先恢复文件夹。之后，每篇文章需要被手动恢复并指定位置。
顶级节点[ ]
典型的eZ Publish 安装会建立以下顶极节点：
- 内容
- 媒体
- 用户
- 设置
- 设计
顶极节点不能为删除。但是，它们可以与其他节点互换。互换可以用来修改顶极节点的类型。例如：“内容”节点引用一个文件夹对象。通过把它与另外一个不同类型的节点互换，可以替换它的类型。下图演示了虚拟根节点和标准的顶极节点：
内容
站点的真实内容保存在“内容”节点下。这个节点通常用来组织文件夹，文章，信息页等内容。因此，定义了站点的内容结构。通过遍历这个顶极节点的内容，可以很容易地生成站点地图。“内容”节点的默认ID 为2。这个节点的内容可以通过在管理界面中选择“内容结构”标签来查看。默认情况下，这个节点引用一个“文件夹”对象。
媒体
“媒体”节点的典型应用是用来保存和组织会被“内容”节点下的节点频繁引用的对象。它通常包含图像，动画，文档和其他文件。例如：它可以用来创建图片集保存可被其他文章使用的图片。“媒体”节点的默认ID 为43。在管理界面中选择“媒体”标签查看它的内容。默认情况下，这个节点引用一个“文件夹”对象。
用户
内建的多用户解决方案使用eZ Publish 原生的内容结构。一个用户实际上就是一个包含“用户帐号”数据类型的类的实体。用户节点被保存在“用户”顶极节点下的“用户组”节点下。换言之，“用户”顶极节点实际上包含用户组和用户。“用户”节点的默认ID 为5。在管理界面中选择“用户帐号”标签查看这个节点的内容。默认情况下，这个节点引用一个“用户组”对象。
设置
“设置”节点包含各种与配置有关的节点。这个节点只用于系统内部。“设置”节点的默认ID 为48。默认情况下，这个节点引用到一个“文件夹”对象。
设计
“设计”节点包含各种与设计相关的节点。这个节点只用于系统内部。“设计”节点的默认ID 为58。默认情况下，这个节点引用到一个“文件夹”对象。
节点可见性[ ]
因为发布意味着添加对象（以节点的形式）到内容树，撤销发布则意味着从内容树中移除对象。一旦对象被发布就不能被撤销因为eZ Publish 不直接提供类似的功能。相反，系统提供了一种隐藏机制来改变节点的可见性。隐藏功能可以用来阻止发布的内容被显示。这是通过拒绝对节点的访问来达到的。单个节点或节点子树可以被用户或系统隐藏。节点可以有以下的可见性状态：
- 可见
- 隐藏
- 由上级隐藏
所有的节点默认为可见，因此他们引用的对象都可以被访问。用户可以通过管理界面隐藏/显示节点。节点被隐藏后，它的所有子孙节点都会被标记为“由上级隐藏”，因而也变为隐藏。如果某节点的父节点被隐藏，则这个节点不能被设置为可见。隐藏的节点将变为不可用，除非"[SiteAccessSettings]"配置区域中的"ShowHiddenNodes"被设置为"true"。
这个配置可以在"site.ini"的重设文件中设置。最常用的配置方法为：对所有除管理界面外的站点入口不允许访问隐藏节点。 实现每个节点有两个标记："H"和"X"。"H"意味着“隐藏”，"X"意味着“不可见”。隐藏标记表示这个节点是否被用户隐藏。"X"为"true"意味着这个节点不可见因为它被用户或系统隐藏。两个标记共同确定了内容树的可见性：
如果用户尝试隐藏一个已经不可见的节点，在不可见标记之外，这个节点的隐藏标记也会被设置。如果一个节点被隐藏并且它的父节点变为可见，这个节点仍然为隐藏状态，而它的子孙节点仍然为不可见状态。下图演示了隐藏算法如何工作。
场景1：隐藏一个可见节点
下图演示了当一个可见节点被用户隐藏后的结果。这个节点会被标记为隐藏。子孙节点会被标记为不可见（由上级隐藏）。已经被标记为隐藏或不可见的子孙节点不会变化。
场景2：隐藏一个不可见节点
下图演示了当一个不可见节点（由上级隐藏）被用户明确地隐藏后的结果。这个节点会被标记为隐藏。因为子孙节点已经为隐藏或不可见状态，它们的可见性不会改变。
场景3：显示一个父节点可见的节点
下图演示了当用户显示了一个有可见父节点的节点后的结果。不可见的子孙节点变为可见。隐藏的子孙节点仍为隐藏（它的子孙节点仍然为不可见）。
场景4：显示一个有不可见父节点的节点
下图显示了当用户显示一个有不可见父节点的节点后的结果。因为目标节点在一个不可见的子树中（因为它的某个祖先节点为隐藏节点），这个节点不会变为可见。相反，它会被标记为不可见并且当它的隐藏祖先节点被显示时变为可见。
对象关联[ ]
eZ Publish 的内容模型允许为不同对象创建关联。任何类型的对象都可以彼此关联。这个特性特别适合用于绑定和/或重用散落在系统内部的各种信息。
例如：关联对象的概念可以把图片添加到文章中。不同于使用固定数量的图片属性，图片可以报存在其它的对象中。这些对象可以被关联到文章并在“XML 块”类型的属性中直接以插图的形式使用。这种方案很灵活，因为它不限制关联对象的数量与类型。
关联类型
对象间的关联可以在对象级别，也可以在对象属性级别实现。系统用相同的数据库表保存对象间不同类型的关联关系。对象不能与自己关联。
对象级别的关联
在3.8 之前的版本中，对象级别的关联是一般性的并且不支持分组。从3.9 版本开始，对象级别的关联有三种类型：
- 通用
- XML 链接
- XML 嵌入
通用
当用户手动将一个对象添加到其它对象的关联对象列表中时（大部分情况下，这是通过对象编辑界面中的“关联对象”窗口来完成的），创建的是“通用”类型的关联。这种方法总是可以使用。
XML 链接
当将一个内部链接（指向另外一个节点或对象的连接）嵌入“XML 块”类型的属性内时，系统会自动创建一个“XML 链接”类型的对象关联。注意，当这个链接标签被删除时，系统会自动删除这个对象关联。
XML 嵌入
当一个"embed"标签被嵌入一个“XML 块”类型的属性中时，系统会自动创建一个“XML 嵌入”类型的对象关联，例如：将对象嵌入到正在编辑的对象。注意，这种类型的关联在"embed“标签被删除时候，会被自动删除。
属性级别的关联
当使用“对象关联（单数）”或“对象关联（复数）”数据类型的属性时，这种类型的关联会被自动创建。第一种数据类型只允许关联一个对象，第二种数据类型允许关联多个对象。对象关联没有分组。但是，通过使用不同的这两种数据类型的属性，可以创建出具有关联分组的自定义数据结构。
分区[ ]
分区是可以指派给对象的一个数字。对象的分区ID 表明这个对象属于哪个分区。每个对象可以属于一个分区。通过为不同对象指派不同的分区ID，逻辑上可以把对象分成很多组。尽管分区机制在对象级别实现，它更多的时候是与节点树一起使用。因此在管理界面中，允许在节点级别管理分区。通过使用分区，可以实现：
- 逻辑上将节点树划分为不同的子树
- 设置自定义的模板重设规则
- 限定与控制对内容的访问
- 对一组商品指派折扣规则
eZ Publish 默认安装会创建以下分区：
在管理界面中可以添加，修改和删除分区定义。下图演示了如何利用分区对内容分段。
行为
当一个新对象被创建，它的分区ID 会被设置为默认分区（通常为标准分区）。当对象被发布时，它会继承父节点的分区。例如：如果在属于分区13 的文件夹中创建对象，这个对象的分区ID 也是13。如果一个对象与多个节点关联，对象的分区ID 为它主节点的父节点的分区ID。此外，如果主节点的变化了，对象的分区ID 也会变化。 可以利用管理界面通过节点树为对象指派分区。当分区被指派到节点，节点对应的对象的分区ID 会改变。
此外，这个节点的子孙节点的分区ID 也会变化。例如，如果一个包含新闻文章的文件夹的分区ID 被修改，那么这个文件夹下的文章的分区ID 也会变化。删除分区会破坏权限设置，模板输出和系统中的其它设置。换言之，除非某个分区完全没有用处，否则不要删除。当删除分区时，只有分区定义会被删除。其它对分区的引用仍然存在，因此系统会处于不稳定的状态。分区ID 不会被循环使用。如果分区被删除，它的ID 不会被其它分区重用。
URL存储[ ]
每个在“XML 块”或“URL ”类型的属性中输入的地址都会在数据库的独立区域保存。这些属性的数据中只保存到URL 表中记录的引用。这种特性允许调查和编辑已发布的URL，而不需要与内容对象互动。URL 表中的地址可以用"linkcheck.php"脚本来检查。这个脚本可以通过eZ Publish 内建的cronjob 脚本来执行。这个脚本会通过逐个访问URL 表中的地址来检查它们时候可用。如果目标服务器返回一个异常的反馈（404 页面丢失，500 内部服务器错误，403 拒绝访问等等）或没有反馈，URL 会被标记为非法URL。用管理界面中的“URL 管理”功能可以很容易地过滤出非法的URL 和使用非法URL 的对象。URL 表中的记录由以下数据构成：
- ID
- 地址
- 创建时间
- 修改时间
- 最后检查
- 状态
每个URL 有一个唯一的数字ID。地址包含真正的链接。创建时间是包含这个URL 的对象的发布时间。修改时间在每次通过管理界面中的URL 管理功能修改URL（不是当包含URL 的对象被修改）时会被修改。每次URL 被脚本检查后，最后检查字段会被修改。URL 的状态可以为“合法”和“非法”。默认情况下，所有的URL 都是合法的。当脚本执行时，它会自动更新URL 的状态。如果发现一个无效的URL，它的状态会被标记为“非法”。如果一个已经存在的URL 被保存，系统会重用现存的记录。
注意：链接检查脚本必须可以通过80 端口与外界通讯。换言之，火墙必须允许从WEB 服务器出栈的HTTP 数据包。
信息收集[ ]
信息收集特性允许在查看一个与信息收集器关联的节点时收集用户输入的数据。它常用于创建反馈表单，投票等功能。一个对象可以用来收集数据，如果它至少有一个被标记为信息收集器的类属性。当对象被显示时，每个收集器属性会用对应数据类型的收集器模板显示。与直接显示内容相反，信息收集器模板提供了数据输入的接口。生成的输入接口依赖于属性的数据类型。下表列出了可用作信息收集器的数据类型。
输入接口必须封装在HTML 表单中，并通过名称为"ActionCollectInformation"的按钮提交 到"/content/action"（"content"模块的"action"视图）。提交的数据会被保存在数据库的特殊部分，与对象分别保存但是与对象保持某种联系。此外，如果对象收集了任何数据，收集的信息可以以电子邮件的形式发送给特性的收件人。在管理界面中“设置”下的“收集的信息”中可以查看和删除收集到的数据。