...
Category | Description |
|---|---|
Traditional | These are nodes identical in format and structure as those found in the traditional nested tables layouts. These nodes represent nodes that this user owns outright, namely folders, tabs and columns, that were created by this user or channels to which this user subscribed. |
Directive | These nodes are used to record changes made by the user on nodes that were incorporated from other layouts via the DLM merge process at login. These nodes are identified by having element names that are part of the 'cp' namespace and include cp:editSet, cp:deleteSet, cp:pref, cp:positionSet, and cp:position. |
Ghost | These nodes are a minimalistic representation of nodes incorporated from another layout and work in combination with directive nodes. These nodes are identified in two ways, first, they have a node ID and a cp:origin attribute both containing a system wide globally unique node ID that looks like 'u' + <userId> + 'l' + <layoutId> + 's' or 'n' + <structId>. This indicates the original layout from which this node was merged into the current user's layout. Additionally, these nodes have a cp:plfId attribute that holds a layout ID that is typical in the traditional layout model. (ie: s27 for folders or n27 for channels.) The value of this attribute corresponds to the structure id by which this node is stored in the user's layout in the database. The cp:origin and cp:plfID attributes combined are the mechanism for persisting nodes of this type in the user's layout using traditional node IDs while maintaining the tie the node incorporated from another layout via the non-traditional globally unique node ID. The purpose of these ghost nodes is to preserve changes made by this user to some incorporated node and allow the DLM merging algorithm to re-apply those changes at log-in time if such actions are still allowed for by the layout owner. |
How each of these nodes is peristed in the database is discussed in
the DLM Data Model page. Lets now look at each of the defined directive nodes used in the PLF and how their use during the merge process causes such changes to appear for a user in the UI.
cp:delete Directives
Any nodes in incorporated fragments that are not marked with a cp:deleteAllowed='false' attribute can be deleted from a user's layout. Such action is recorded in a top level cp:deleteSet element that contains a single cp:delete node for each node deleted from the incorporated fragments. This does not mean one entry for each node contained in the node deleted. It only represents the pruning point node.
For example, suppose that an we have a fragment targeted at all users that has a "All Users" fragment contained an "All Users Sample" tab with some helpful content.For example It also contains to by this userUser's Sample" tab in it having a global node ID of 'u11l1s8' and the fragment owner allowed users to delete that tab. If a user deleted that node then the PLF portion recording such a change would look like this. Notice that only the node ID for the tab is represented not everything below the tab even though the tab and all of its contents will be removed upon log-in for this user.
If instead the "All User's Sample" tab had three columns two of which having node IDs of 'u1l1s14' and 'u1l1s22' were deleted by the user, the delete set would look like this.
cp:editSet
TBD:mboyd: user id 23 has edit set ready for capture for this section's description.