Sungard SCT's Layout DOM Model
- Mark Boyd
This page is part of the Aggregated Layout Management Convergence 2.x effort that will be added to 3.x.
There are two internal representations of a user's layout in the DLM world. The first is the Integrated Layout Fragment or ILF and represents the layout viewed by the user in the browser including UI elements merged in from other layouts. The other is known as the Personal Layout Fragment or PLF and contains the layout for a user as found in the database tables. When changes are made by a user to their layout, ie: the ILF since that is what they are viewing, the system determines if these were changes to a user-owned node or an incorporated node and will then make modifications necessary to the PLF to reflect that change the next time that this user logs in. Then the PLF is persisted to the database.
Integrated Layout Fragment (ILF)
The ILF model is rather simple. It looks just like a traditional nested table model. The only real difference is that the IDs of some nodes have an extended format to represent a system-wide unique node ID. Such nodes were incorporated from another layout and their IDs are morphed at merge time in a way to provide traceability back to the original node in the original layout fragment and elliminate ID collisions with nodes owned by the current user of the layout fragment. Since the ILF is identical to the nested table DOM it works as is in the portal with only minor changes to the structure and theme transformations.
Personal Layout Fragment (PLF)
The PLF model contains three categories of nodes. Categories in this discussion do not map to some attribute on the nodes. It is only a term used for this discussion.
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 we have a fragment targeted at all users that has a "All User'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.