Object - node relation
|
This part of the 4.x documentation is for eZ Publish 4.0, only reference section is common for all eZ Publish 4.x versions as well as eZ Publish 5.x "LegacyStack", please select the version you are using for the most up to date documentation! |
When the system is in use, new content objects are created on the fly. For example, when a news article is composed, a new article object is created. Obviously, the content objects can't just hover around in space, they have to be organized in some way. This is where the nodes and the content node tree comes in. A content node is nothing more than an encapsulation of a content object. In eZ Publish, every object is usually represented by one or more nodes. The following illustration shows a simplified example of a node and a corresponding object (which is referenced by the node) as it would have been represented inside the system.
Object - node relation
The content node tree is built up of nodes. A node is simply a location of an object within the tree structure. The tree is the actual mechanism used to hierarchically organize the objects that are present on the system. The content node tree is explained in the next section.
A content node consists of the following elements:
Every node has a unique identification number. The ID numbers are used by the system to organize and keep track of the different nodes. These ID numbers are not recycled. In other words, if a node is deleted, the ID number of that node will not be reused when a new node is created.
The parent node ID of a node reveals the node's superior node in the tree.
Every object that exists in the system has a unique identification number. The object ID of a node pinpoints the actual object that the node encapsulates.
The sorting method of a node determines how the children of the node should be sorted. The following sorting methods are possible:
| Method | ID | Description |
|---|---|---|
| Class identifier |
6 |
The nodes are sorted by the class identifiers of the objects. |
| Class name |
7 |
The nodes are sorted by the class names of the objects. |
| Depth |
5 |
The nodes are sorted by their depth in the tree. A node further down in the three has a higher level of depth. The root node has a depth of 1. |
| Modified |
3 |
The nodes are sorted by the modification time of the objects. |
| Modified subnode |
10 |
The nodes are sorted based on the modification time of their children. |
| Name |
9 |
The nodes are sorted by the names of the objects. |
| Path |
1 |
The nodes are sorted by their path strings. |
| Priority |
8 |
The nodes are sorted by their priority. Every node has a priority field that can be set by the user. This solution allows the nodes to be sorted in a custom order. The priority field is described below. |
| Published |
2 |
The nodes are sorted by the creation time of the objects' current/published versions. |
| Section |
4 |
The nodes are sorted by the section IDs of the objects. |
Please note that it is possible to combine the available sort methods in order to sort nodes in a more complex way. However, since a node is incapable of "remembering" a combination (you can only set one method and one order for each node), this has to be done in the templates.
The sorting order determines the order in which the children of the node should be sorted. There are two possibilities:
For example, if the sorting method is set to "Name" and the sort method is set to "Ascending", the underlying nodes will be alphabetically sorted from A to Z. If the sort method is set to "Descending", the underlying nodes will be sorted from Z to A.
The priority field allows a user to assign both positive and negative integer values to a node (zero is also allowed). This field makes it possible to sort nodes in a custom way. If the sorting method of a node is set to "Priority", the children of that node will be sorted by their priorities.
Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2013 eZ Systems AS (except where otherwise noted). All rights reserved.