The content node
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.
Node structure
A content node consists of the following elements:
- Node ID
- Parent node ID
- Object ID
- Sort method
- Sort order
- Priority
Node ID
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.
Parent node ID
The parent node ID of a node reveals the node's superior node in the tree.
Object ID
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.
Sort method
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.
Sort order
The sorting order determines the order in which the children of the node should be sorted. There are two possibilities:
- Descending (0 / FALSE)
- Ascending (1 / TRUE)
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.
Priority
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.
Balazs Halasy (14/09/2010 10:56 am)
Geir Arne Waaler (28/09/2010 8:39 am)
Comments
There are no comments.