Properties Defined dlm:property tag explained.
Fragments Defined dlm:fragment tag explained.
Roles Defined dlm:role tag explained.
Audiences Defined dlm:audience tag explained.
<managedLayoutFragments xmlns:dlm="http://www.campuspipeline.com/uportal/dlm">
<dlm:property name='defaultLayoutOwner' value='fragmentTemplate'/>
<dlm:property name='layoutDecorator' value='com.pipeline.uportal.dlm.provider.CpLayoutDecorator'/>
<dlm:property name='campuspipeline.uportal.dlm.debug' value="false"/>
<!-- Controls clearing of dlm fragment cache. This allows changes made to layout
owners to be reflected once the cache has been updated. Specified in minutes. -->
<dlm:property name='campuspipeline.uportal.dlm.fragment_cache_refresh' value="60"/>
<dlm:fragment name='Faculty' ownerID='faculty-lo' precedence='50'>
<dlm:role>faculty</dlm:role>
<dlm:audience evaluatorFactory='com.pipeline.uportal.dlm.provider.CPPersonEvaluatorFactory'>
<attribute name='role' mode='equals' value='faculty'/>
</dlm:audience>
</dlm:fragment>
<dlm:fragment name='All Users' ownerID='allusers-lo' precedence='100'>
<dlm:audience evaluatorFactory='campuspipeline.uportal.dlm.provider.AllUsersEvaluatorFactory'/>
</dlm:fragment>
<dlm:fragment name='Students' ownerID='student-lo' precedence='100'>
<dlm:role>student</dlm:role>
<dlm:audience evaluatorFactory='com.pipeline.uportal.dlm.provider.CPPersonEvaluatorFactory'>
<paren mode="AND">
<attribute name='role' mode='equals' value='student'/>
<paren mode="NOT">
<attribute name='role' mode='equals' value='faculty'/>
</paren>
</paren>
</dlm:audience>
</dlm:fragment>
<dlm:fragment name='Employee' ownerID='employee-lo' precedence='30'>
<dlm:role>employee</dlm:role>
<dlm:audience evaluatorFactory='com.pipeline.uportal.dlm.provider.CPPersonEvaluatorFactory'>
<attribute name='role' mode='equals' value='employee'/>
</dlm:audience>
</dlm:fragment>
</managedLayoutFragments>
Properties Defined
There are currently four properties understood by the DLM infrastructure.
Property |
Description |
|---|---|
defaultLayoutOwner |
The user account whose layout will be used to perform a cookie cutter copy for newly created fragment owner accounts when they first log in. This concept is similar to the usertemplate account for new uPortal users. |
layoutDecorator |
The fully qualified name of a class that is delegated to by the DLM infrastructure immediately after all layout merging has taken place at log-in time. This class can then add layout information and is used to implement the cp:info functionality. PersonDirs.xml can replace nearly all cp:info functionality. |
campuspipeline.uportal.dlm.debug |
You can guess what this property was for. It was a way to turn on debugging in the DLM infrastructure without incurring scrolling blindness by turning on debugging system wide in uPortal. With the switch to commons logging and log4j this is no longer needed. |
'campuspipeline.uportal.dlm.fragment_cache_refresh |
As noted in the comment this value indicates how often changes are reloaded that are made to the layouts of fragment owner accounts. |
Fragments Defined
The <dlm:fragment> element has four possible attributes, one optional nested <dlm:role> element (see Roles Defined), and zero to many nested <dlm:audience> elements or comments. The audience elements indicate to whom the fragment will go. See Audiences Defined for more detail.
Attribute |
Description |
|---|---|
name |
A required unique name by which this fragment is known |
ownerID |
The required login id of the user who owns the distributed layout and hence can edit the layout. There was no UI created three years ago when this ALM approach was constructed. For speed the layout of a regular account was used to specify the fragment. So each fragment must have a corresonding account created solely for defining what that fragment entails. This also means that the smallest fragment that can be created is a tab. With a fragment specific creation UI such a restriction will be removed. |
precedence |
A required positive, decimal number or zero. Negative numbers are not allowed. This number is used to indicate the ordering of layouts for a user during their layout construction sequence. When a user logs in the system asks each distributed layout if it is applicable to that user. (See Audiences Defined below.) Those that answer yes are placed in a layout construction sequence in order of precedence, the higher the number the higher the precedence and the earlier the layout will be merged into the user's viewed or constructed layout. Layouts merged in prior to other layouts have higher precedence and hence can restrict actions taken by layouts merged in later enforcing such things as position for their elements. A user's personal layout fragment, that portion representing changes made to incorporated layouts, has a precedence of zero. If two or more layouts have the same value then their precedence is determined by their order in this file. Those at the top have higer precedence than those appearing later. |
defaultLayoutOwner |
This is an optional attribute. If included then it identifies the default user whose layout is copied for this fragments layout when the fragment owner first logs in. If not included it defaults to the value of the only defined property element of the same name declared in this file. If neither is defined then the default is the user indicated by the org.jasig.portal.services.Authentication.defaultTemplateUserName property in portal.properties. |
Roles Defined
The roles element determines to what group a fragment owner will belong. The fragment owner is defined by the ownerID attribute of the containing fragment element and represents the user account whose layout is used as the layout for the fragment. When modifying the layout, channels can be added. Channels are themselves granted only to certain groups of users. As such there is the potential for a fragment owner to have one group membership and the users of that fragment to have other disjoint group memberships. In such cases channels added to the surface of that layout and them merged into the user's layouts will show up as broken and indicate that the user does not have access to that channel.
The role element is a step toward resolving such problems. Upon loading dlm.xml the infrastructure looks to see what groups the fragment owner is a member and removes them from all groups except the one indicated by the role element. Additionally, if they are not a member of this group then they are made a member of that group.
New features slated to be added as part of the ALM Convergence effort will render this declaration. The goal is for the fragment editing UI to indicate which channels added to the fragment may not be available to all users of the fragment as defined by the set of users to whom the fragment is published for pushed fragments or the users who can subscribe to the fragment for pulled fragments.
Audiences Defined
Coming soon....