<?xml version="1.0" encoding="utf-8"?>



<content>

<title>Distributed Layout Management</title>



<section>

<title>Whence Came This Tab?</title>

<p>If you are seeing this channel for the first time chances are you just turned on a feature known as <em>Distributed Layout 

Management</em> or <em>DLM</em>. Of the tabs in this page, this one is unique. Most are part of the guest user's own layout. 

This tab isn't. In DLM terminology it is a <em>fragment</em> that was merged in by DLM. Traditionally, if you wanted to change what 

guests see you would set a password for the guest user, log in as guest, and change the layout. Not with DLM. <em>To 

change the contents of this tab</em> log in with the following user id and password:

</p>

<p>

User Id: <strong>guest-lo</strong>, Password: <strong>guest-lo</strong>

</p>

<p>

This user is a DLM fragment owner. This account has all of the same capabilities 

as a regular user with one exception, <em>no fragments are merged into a fragment owner's layout</em>. Fragment owners 

see only their owned layout since that layout becomes the fragment that is pushed into other layouts. 

</p>

<p>

Now once you log in, change the guest fragment, and log out, <em>you will notice that this tab didn't change</em>. Doesn't DLM push 

changes to the guest layout? Of course it does. The problem here is that the guest layout that you see is cached in a layout 

manager. For regular users a layout 

manager is loaded when they log in. Hence, so is their layout. The guest layout manager is loaded when the first request is

made to the portal after starting up and is cached in memory thereafter. So changes made to fragments that go to regular users 

will present their changes the next time that a user logs in after that fragment has been changed. But currently, to see changes pushed to the 

guest layout, the portal must be restarted. This will be fixed soon.

</p>

<p>

<em>To learn more about DLM select any of the links to the left.</em>

</p>

</section>

<section>

<title>Whence Came DLM?</title>

<p>In uPortal, Layout Management refers to how the user interface seen by a user is generated and changed. In version 2.0,

only Simple Layout Management, SLM, was available in the portal. All layout pieces like tabs,

columns, and channels were owned by the user. There was little control available for an institution to control a user's layout. 

When Sungard SCT, then Campus Pipeline, adopted uPortal for their Luminis product they had to allow <em>schools</em> to <em>choose how much 

or how little</em> of the layout <em>is locked in place</em>. Furthermore, this should be modifiable at any time and such 

changes should then appear in the portal. The result was Distributed Layout Management or DLM which debuted in Luminis in 2002.

</p>

<p>This resulted in JA-SIG designing a similar feature known as Aggregated Layout Management or ALM. With the advent of ALM there

were two approaches to dynamic layout management. However, although they have complimentary features, ALM and DLM each provide benefits 

that are not had by the other implementation. In 2004 Sungard SCT was contacted to see if the features of ALM and DLM could converge 

into a single offering. The benefits are obvious. With the community working to enhance the features of a single offering all will 

benefit. Accordingly, work was started in late 2004 to contribute DLM back to the community and have it available starting in uPortal 

version 2.5.0.

</p>

<p>

<em>To learn more about configuring DLM select the related links to the left.</em>

</p>

</section>



<section>

<title>Introducing dlm.xml</title>

<p>When DLM was developed, time was of the essence. A new user interface taylored to building fragments and a new database schema was 

too aggresive an undertaking for engineers new to the uPortal code base. Upon further investigation of the portal architecture and 

database schema it was determined that a derivative approach could be taken instead. In a derivative approach, existing, reliable 

pieces of the portal could be used to produce layout fragments to be pushed to users. Furthermore, there would be no database schema 

changes. Specifically, fragments would be obtained by using regular portal accounts to 

define what each fragment should look like. Such was and is the design of DLM. A configuration file, <strong>dlm.xml</strong>, <em>defines fragments, 

their audiences, and the special portal accounts used to set up their layouts.</em> (See Future Direction 

on how dlm.xml will be replaced in the near future.)

</p>

<p>Although dlm.xml is xml based it does not have a defined schema or DTD. Its expected structure is defined by the expectations of 

the DLM loading infrastructure. This is in part due to the extensible nature of dlm.xml as will be seen in the declarations of the 

fragment audience definitions. Therefore, the remaining information in this section and related sections will portray the implicit 

structure expected by the DLM loading infrastructure.

</p>

<p>The dlm.xml file is <em>located in the properties</em> directory. The top level element in dlm.xml is the &lt;managedLayoutFragments> element. 

It includes the namespace declaration for DLM used to prefix 

all expected DLM property, fragment, and audience elements. This element appears as follows in dlm.xml.

</p>

<p><code>

  &lt;managedLayoutFragments xmlns:dlm="http://org.jasig.portal.layout.dlm.config">

</code></p>

<p>The only two supported child elements for <em>managedLayoutFragments</em> are &lt;dlm:property> and &lt;dlm:fragment>. Others may 

be included but they will be ignored. The <strong>&lt;dlm:property></strong> element has two required attributes, <em>'name'</em> and <em>'value'</em>. 

There are currently only two properties supported by DLM and if not defined, suitable defaults will be used as explained below.

</p>

<p><strong>The 'defaultLayoutOwner' Property</strong></p>

<p>If defined the value of this property should be the user ID (ie: the log-in ID) of an account whose layout should be copied for all 

new fragment owners. When a fragment is defined in dlm.xml it includes an <em>ownerID</em> attribute. (See the related section on defining 

fragments.) Since fragments are layouts for special accounts then these accounts must have a layout. When regular users log in for 

the first time and have no layout, the portal gives them a copy of a default account's layout as declared in portal.properties. This 

default should not be used for fragment owner accounts since it will result in that entire layout being pushed to all users. The 

approach take by the default dlm.xml is to use a special account included in the portal. To change this account you can use 

the following credentials.</p>

<p>

User Id: <strong>fragmentTemplate</strong>, Password: <strong>fragmentTemplate</strong>

</p>

<p><strong>Warning:</strong> It is strongly recommended that you do not change this user account's layout. It is empty except for 

hidden content like the header and footer folders and their channels. The layout for this account including hidden but necessary content 

is copied whenever a new fragment 

owner is declared in dlm.xml. The layout for the owner account is created immediately after adding the fragment's declaration to 

dlm.xml and restarting the portal. These accounts should 

be empty until such time that the account can be accessed and the proper layout set up that should be pushed for that fragment.

</p>

<p><strong>The 'org.jasig.portal.layout.dlm.RDBMDistributedLayoutStore.fragment_cache_refresh' Property</strong></p>

<p>For performance, DLM caches the layout for each defined fragment in memory. When layout owners modify the layout, those changes are 

pushed into the database and into the in-memory cache in the server handling the session for that account. If multiple servers are 

employed, the other servers will not see these changes 

made by the fragment owner. This property determines how often the cache of fragment layouts is reloaded to 

force such changes to appear in other servers. This does not include instantiating new fragments declared in dlm.xml. This only 

forces a reload of the fragments seen in dlm.xml when the servers were last restarted.

</p>

<p>

<em>To learn more about DLM select any of the links to the left.</em>

</p>

</section>



<section>

<title>Defining Framents</title>

<p>The &lt;dlm:fragment> child element of the outer most <em>managedLayoutFragments</em> element is used to define a fragment. There 

is no restriction on the number of child &lt;dlm:fragment> elements of <em>managedLayoutFragments</em>. The following sample is one 

of the fragments defined in the default dlm.xml file that comes with uPortal.

</p>

<p><code>

  &lt;dlm:fragment name='Guests' ownerID='guest-lo' precedence='10'>

   &lt;dlm:audience evaluatorFactory='org.jasig.portal.layout.dlm.providers.GuestUserEvaluatorFactory'/>

  &lt;/dlm:fragment>

</code></p>

<p></p>

<p><strong>The 'name' Attribute</strong></p>

<p>

All elements defined and expected by DLM are prefixed with <em>dlm</em> indicating that they are part of the DLM namespace. The fragment 

element has a <strong>name</strong> attribute that should be unique for all fragments. This name is presented in the title bar of the portal when the owner of this fragment 

is logged in as shown below.

</p>

<p><image>fragmentTitleBar.jpg</image></p>

<p></p>

<p><strong>The 'ownerID' Attribute</strong></p>

<p>

Each fragment must declare an <strong>ownerID</strong> attribute. This is the log-in to use when logging in to edit 

the layout for this fragment. <em>It is important that this account not exist prior to adding the fragment</em>. When dlm.xml 

is modfied, the portal must be restarted for the configuration to be loaded. Upon loading, if that account already exists and has a 

layout it will immediately be pushed to users. If the account does not exist, then upon restarting the portal, DLM will create that 

account and populate its layout with a copy of the layout of the account specified with dlm.xml's <em>defaultLayoutOwner</em> 

property. That layout has no visible content. In this way this fragment does not push any content to users until the owner has time 

to set up the layout 

that should be pushed. <strong>Note:</strong> the md5passwd command line utility must still be used after restarting 

to set the password for the new account to allow a fragment maintainer to log in to that account and set up the layout:<code>ant md5passwd -Dusername=guest-lo</code> 

</p>

<p></p>

<p><strong>The 'precedence' Attribute</strong></p>

<p>Each fragment must also declare an integer <strong>precedence</strong> value. This value is used during merging of fragments to 

position elements contributed from different fragments. It is also used to determine that precedence elements 

can override a lower precedence, movement-restricted element forcing it to a less valueable real-estate location. For example, the default dlm.xml file defines three 

fragments:

<code>Guests: precedence = 10

Entertainment: precedence = 100

News: precedence = 80

</code>

When a regular user, in this case the student account, logs in to the portal and selects the <em>Preferences</em> link the following ordering of tabs will appear. Note that the 

entertainment tab can move to the right of the news tab but that the student tab is not allowed to move to the left of the news tab. 

</p>

<p><image>tabs_ent_news_stu.jpg</image></p>

<p>

This behavior is due to the owner of the news tab's fragment marking the news tab as <strong>not moveable</strong>. However, 

restricting movement is relative. All elements from a fragment inherit the precedence of that fragment. A tab from a fragment with 

higher precedence like the entertainment tab, can override a movement restriction of a lower precedence tab. </p>

<p><image>tabs_news_ent_stu.jpg</image></p>

<p>

Now the student tab is owned by the student user. <em>User layout elements have a 

precedence of zero</em> and hence any fragment element can always force user owned elements to lower-valued real-estate locations. 

However, if a fragment element has not been movement restricted then lower precedence tabs can move them as is shown below with the 

student tab moved to the left of the entertainment tab. But note that due to the locked news tab and the relative precedences that 

the student tab is never allowed to move beyond the news tab.</p>

<p><image>tabs_news_stu_ent.jpg</image></p>

<p>

As can be seen, movement restrictions restrict movement of lower precedence elements to higher valued screen real-estate locations. 

<em>DLM allows 

users to alter fragment elements pushed into their layouts if such changes are allowed by the fragment</em>. This means that users can add columns to fragment tabs 

and channels to fragment columns. Accordingly, real-estate 

value differs based on element type. For tabs, the most valued real-estate is furthest to the left since tabs to the right can 

ultimately be forced off of the right side of the page and outside the view being shown by the browser. Columns have a similar value 

direction of left to right from highest to lowest value for a similar reason. Channels have a direction from the top of a column to 

the bottom for highest to lowest value respectively since channels further down in a column can be forced off of the bottom of the 

browser's visible viewing area.</p>

<p>

<em>To learn more select the related links to the left.</em>

</p>

</section>



<section>

<title>Defining Audiences</title>

<p>Each &lt;dlm:fragment> element can contain from zero to many &lt;dlm:audience> elements. Each audience element defines a group of 

users who will receive that fragment. If a fragment has more than one audience element then the set of users that get that fragment 

is the union of all nested audience elements. 

</p>

<p><strong>The 'evaluatorFactory' Attribute</strong></p>

<p>

The &lt;dlm:audience> element has a single required attribute, <em>evaluatorFactory</em>. This attribute should have the fully 

qualified path name of a class which implements the org.jasig.portal.layout.dlm.EvaluatorFactory interface for aquiring an evaluator. 

The factory implementation should have a zero argument constructor and implement the only method in the interface: 

</p>

<p><code>

     public Evaluator getEvaluator( org.w3c.dom.Node audience )

     throws Exception;

</code></p>



<p>The DLM infrastructure will instantiate the factory using the zero argument constructor and call <em>getEvalutator</em> 

passing a node representing the &lt;dlm:audience> element. This can then be used by the factory to return an evaluator 

appropriate for any configuration information included within the audience block. This means that the <em>contents of the audience 

element are dictated completely by the declared EvaluatorFactory</em>.

</p>

<p>

The object returned from <em>getEvaluator</em> must implement the org.jasig.portal.layout.dlm.Evaluator interface as shown below.

</p>

<p><code>

     public boolean isApplicable( IPerson p )

</code></p>

<p>DLM obtains from each audience's factory an evaluator and when a user logs in it passes through every fragment asking its audience 

evaluators, <em>isApplicable</em>, passing an IPerson implementation. If the user meets the requirements defined for that audience 

then the method returns a value of true and that fragment is included in the layout for that user. If the factory is unable to create 

and return an evaluator it should throw an Exception with a clear message indicating the problem. For example, suppose the &lt;dlm:audience> 

element were as follows:

</p>

<p><code>

  &lt;dlm:audience evaluatorFactory="IPersonEvaluatorFactory"/>

</code></p>

<p>This would result in the IPersonEvaluatorFactory, to be explained shortly, throwing an exception with the following message since 

it requires nested configuration content:

</p>

<p><em>Invalid content. Expected one to many &lt;paren>, &lt;NOT>, or &lt;attribute> in '&lt;dlm:audience evaluatorFactory="IPersonEvaluatorFactory"/>'</em></p>

<p>If an exception is thrown when obtaining an evaluator from an evaluator factory then the message is logged as a warning and the 

audience element in question is discarded and not included in the evaluators for that layout fragment. Other evaluators for that 

layout would still be in effect.

</p>

<p>The following evaluator factories are provided. All are found in the <em>org.jasig.portal.layout.dlm.providers</em> package.

</p>

<p><strong>The GuestUserEvaluatorFactory</strong></p>

<p>This factory produces and evaluator that returns the value of <em>IPerson.isGuest()</em>. As such it does not use any 

configuration information within the audience element that declares it so the element can be empty. This factory is used in the 

version of dlm.xml included in the portal to push the Guest fragment to the guest user so that it shows on the log-in page.

</p>

<p><code>

  &lt;dlm:fragment name='Guests' ownerID='guest-lo' precedence='10'>

   &lt;dlm:audience evaluatorFactory='org.jasig.portal.layout.dlm.providers.GuestUserEvaluatorFactory'/>

  &lt;/dlm:fragment>

</code></p>

<p><strong>The AllUsersEvaluatorFactory</strong></p>

<p>This factory produces and evaluator that always returns true. This can be used to push a fragment to all portal users 

<em>including</em> the guest user. Like GuestUserEvaluatorFactory it requires no content within the audience element and hence the 

element can be empty.</p>

<p><strong>The PersonEvaluatorFactory</strong></p>

<p>This factory produces an evaluator configured as defined by required content nested within its declaring audience element. It supports a 

configuration syntax from which arbitrarily complex grants of the fragment can be made based on attributes found in the passed-in 

IPerson object. Specifically, it obtains attributes from the IPerson object using the <em>getAttribute</em> call. The following 

syntax elements are supported.

</p>

<p><em>&lt;paren> ELEMENT</em></p>

<p>This element has one optional attribute "mode" which can contain one of three cast-sensitive values: <em>OR</em>, which is the default, 

<em>AND</em>, or <em>NOT</em>. <em>OR</em> causes the paren element to evaluate all contained tests and if any of them returns true then it too will 

return true. <em>AND</em> returns true only if all contained tests are true. <em>NOT</em> inverts any contained test. If more than 

one contained test is included then a logical <em>OR</em> operation is performed first and that result inverted. It should be noted 

that when PersonEvaluatorFactory factory is used it provides an implicit &lt;paren mode="OR"> element into which all child elements 

of &lt;dlm:audience> are placed. So if your configuration requires such a top level paren element you can just specify its children 

within the &lt;dlm:audience> element.

</p>

<p><em>&lt;attribute> ELEMENT</em></p>

<p>This element is used to specify which one of five available tests should be performed on an attribute in the passed-in IPerson object. The particular attribute to be tested is 

indicated in the required <em>name</em> attribute. The required <em>mode</em> attribute indicates the type of test and can be one of 

the following: <em>exists</em>,<em>equals</em>, <em>contains</em>, <em>startsWith</em>, and <em>endsWith</em>. The value to be 

compared is indicated by the <em>value</em> attribute. The <em>value</em> attribute is not required and indeed not used for the 

"exists" mode. Values for both mode and name are case sensitive. 

</p>

<p>The Entertainment fragment included in the default dlm.xml file in the portal uses this factory to push the entertainment fragment 

to all users that do not have a "username" attribute with a value of "guest".

</p>

<p><code>

  &lt;dlm:fragment name='Entertainment' ownerID='ent-lo' precedence='100'>

    &lt;dlm:audience evaluatorFactory='org.jasig.portal.layout.dlm.providers.PersonEvaluatorFactory'>

      &lt;paren mode="NOT">

        &lt;attribute name="username" mode='equals' value='guest'/>

      &lt;/paren>

    &lt;/dlm:audience>

  &lt;/dlm:fragment>

</code></p>

<p><strong>The GroupMembershipEvaluatorFactory</strong></p>

<p>This factory returns an evaluator that can evaluate group memberships. Specifically, the returned class inherits from the 

evaluator provided by PersonEvaluatorFactory. This means that its syntax semantics are identical except for the &lt;attribute> 

element. Its semantics are overwritten to support only a single mode, <em>memberOf</em>. The <em>name</em> attribute should contain the 

name of the group with matching case. The <em>value</em> attribute is not used. The News fragment in the default dlm.xml 

file in the portal uses this factory to push the news fragment to members of the Students group who are not also members of the 

Faculty group.

</p>

<p><code>

  &lt;dlm:fragment name='News' ownerID='news-lo' precedence='80'>

    &lt;dlm:audience evaluatorFactory='org.jasig.portal.layout.dlm.providers.GroupMembershipEvaluatorFactory'>

      &lt;paren mode="AND">     

        &lt;attribute mode='memberOf' name='Students'/>

        &lt;paren mode="NOT">

          &lt;attribute mode='memberOf' name='Faculty'/>

        &lt;/paren>

      &lt;/paren>

    &lt;/dlm:audience>

  &lt;/dlm:fragment>

</code></p>

<p><strong>Note:</strong> dlm.xml was designed to allow institutions the ability to define and plug-in their own custom evaluators. 

The dlm.xml file will be replaced in the near future with the new permissions work that is targeted for uPortal 2.6.0. That solution 

will have more flexibility 

than is had with the current design of dlm.xml. For example, although completely different technology, logically the new solution 

blurs the boundary between audience elements allowing person attribute 

tests to be combined in the same boolean equation as group membership evaluations. When DLM migrates to that new approach only these 

classes and their semantics are guaranteed to be migrated. Any configuration added via custom factories from an institution will 

have to be planned for and migrated by that institution as part of upgrading to the version of DLM in 2.6.0. 

</p>

<em>To learn more select the related links to the left.</em>

</section>



<section>

<title>Setting up Fragment Layouts</title>

<p>Once a fragment is defined in dlm.xml, the server bounced, and the password configured for the new fragment owner account, a 

fragment maintainer can log into that account and set up the layout that should be used for that fragment. For this, an extended 

version of SimpleLayoutManagement's Preferences channel is provided and is the channel seen when using DLM and the Preferences link 

is selected. For non-fragment users they see that channel in the traditional manner. For fragment owner the preferences channel 

changes slightly to indicate the name of the fragment that is being edited as can be seen in the images below. Additionally, 

controls are added to the user interface to provide the ability to restrict what users of the fragment can do to fragment elements.

</p>

<p><strong>Tabs</strong></p>

<p>In the image below the typical controls for a tab are shown along with some DLM specific fragment-user-actions that can be 

restricted. By default all check boxes are selected and hence all actions are allowed by end users. As seen in the image, the 

"Useful News" tab in the News fragment's layout restricts movement by end users of the fragment. To modify any of these actions the 

appropriate checkbox should be checked or unchecked as needed and the "Set Actions" button pressed. Each of these actions that can 

be restricted for tabs is discussed below.

</p>

<p><image>fragmentTabEdit.jpg</image></p>

<p><em>Move Tab</em></p>

<p>If moving a tab is restricted by a fragment owner then users will not be able to move any of their personally-added tabs to the 

left of this tab. If any tabs exist in the user's layout that come from a fragment with lower precedence as declared in dlm.xml then 

the user will also be unable to move those tabs to the left of this tab. Tabs from a fragment with higher precedence can be moved by 

the end user to the left of this tab. If any of these lower precedence tabs or user-added tabs 

were moved to the left of this tab prior to it being marked as movement restricted then those tabs will be pushed to the right of 

this tab when the user next logs back in. To the end user the inability to move a lower precedence tab including those added by the 

user is depicted by the lack of the buttons allowing the user to move the tab to the left as seen in the image below.

</p>

<p><image>tabs_news_stu_ent.jpg</image></p>

<p><em>Edit Properties</em></p>

<p>If editing tab properties is restricted by a fragment owner then users will not be able to rename that tab in their layout. If a 

user has previously renamed that tab and the fragment owner then marks the tab to prevent editing of properties then the next time 

that the user logs in that tab name change will be discarded and the name set by the fragment owner will reappear. When such a tab is 

restricted from editing the controls for renaming that tab are removed from the user's view when selecting that tab as shown in the 

image below. The "Real Entertainment" tab has editing of properties restricted as can be seen by the missing renaming elements when 

viewed by the student user.

</p>

<p><image>userFragTabEditPropRest.jpg</image></p>

<p><em>Add Columns</em></p>

<p>If adding columns is restricted by a fragment owner then users will not be able to add columns to that tab in their layout. If a 

user has previously added columns to that tab and the fragment owner then marks the tab to prevent adding columns then the next time 

that the user logs in <em>those user columns will be discarded</em>. (There is currently no holding place to such discarded items. 

Such a holding place similar to the waste basket concept could be added if there was a pressing needed and a channel could be created to 

allow a user to restore those items to some other location in their layout.) When such a tab is 

restricted from adding columns the "Add Column" buttons are removed from the user's view when selecting that tab as shown in the 

image below. The "Useful News" tab has adding columns restricted as can be seen by the missing buttons in the spaces between and to 

the left and right of columns when viewed by the student user.

</p>

<p><image>userAddColsRest.jpg</image></p>

<p><em>Delete Tab</em></p>

<p>If deleting the tab is restricted by a fragment owner then users will not be able to delete this tab from their layout. If a 

user has previously deleted this tab and the fragment owner then marks the tab to prevent deleting then the next time 

that the user logs in, that tab will reappear. When such a tab is 

restricted from being deleted the "Delete this tab" link is removed from the user interface for that tab when end users are editing 

their layout.

</p>

<p><strong>Columns</strong></p>

<p>The action-restricting controls for columns are nearly identical to those of tabs as is their application.</p>

<p><em>Move Column</em></p>

<p>If moving a column is restricted by a fragment owner then users will not be able to move any columns that they have added to the 

tab to the left of this column assuming that the tab allowed them to add their own columns. If any user-added columns have were 

previously added to the left of this column and the fragment owner marked this column as movement restricted then those user 

added columns will be bumped to the right of this column the next time that the user logs in. Additionally, the buttons for moving 

those user added columns to the left of this column are removed from the user interface when a user is editing that tab in their layout.

</p>

<p><em>Edit Properties</em></p>

<p>Restriction of column property editing is identical to restriction of tab property editing except that the only property that 

currently exists for columns is width. If editing column properties is restricted by a fragment owner then users will not be able to 

change the column's width. They can read it but they can't change it as shown in the image below. Note that only one of these 

columns is marked as being edit restricted.

</p>

<p><image>userFragColEditPropRest.jpg</image></p>

<p><em>Add Channels</em></p>

<p>If adding channels is restricted by a fragment owner then users will not be able to add channels to that column in their layout. 

If a user had previously added channels to that column and the fragment owner then marked the column to prevent adding channels then 

the next time that the user logs in <em>those user added channels will be discarded</em>. When such a column is 

restricted from adding channels, all "Add Channel" buttons are removed from the user's view of that column.

</p>

<p><em>Delete Column</em></p>

<p>If deleting the column is restricted by a fragment owner then users will not be able to delete this column from their layout. 

Additionally, <em>the user will not be able to delete the tab containing this column</em>. When such a column is 

restricted from being deleted the "Delete this column" link is removed from the user interface for that column and the "Delete this 

tab" link is removed for its containing tab when end users are editing their layout.

</p>

<p><strong>Channels</strong></p>

<p>The action-restricting controls for channels vary from those of columns and tabs in that only move and delete are restricted.</p>

<p><em>Move Channel</em></p>

<p>If moving a channel is restricted by a fragment owner then users will not be able to move any channels that they have added above 

this channel assuming that the column allowed them to add their own channels. If any channels were 

previously added above this channel and the fragment owner marked this channel as movement restricted then those user 

added channels will be bumped below this channel the next time that the user logs in. Additionally, the buttons for moving 

those user added channels above this channel are removed from the user interface when a user is editing the column containing that 

channel in their layout.

</p>

<p><em>Delete Channel</em></p>

<p>If deleting a channel is restricted by a fragment owner then users will not be able to delete that channel from their layout. 

Additionally, <em>the user will not be able to delete the containing column and tab</em>. If any of these were previously removed by 

the user and the fragment owner then marked that channel as undeletable then the tab and all of its columns and channels would 

reappear the next time that the user logged in. When such a channel is 

restricted from being deleted the delete button for the channel is removed from the user interface when an end user is editing their 

layout. Additionally, the "Delete this column" link is removed from the user interface for that channel's containing column and the 

"Delete this tab" link is removed for its containing tab.

</p>

<em>To learn more select the related links to the left.</em>

</section>



<section>

<title>Future Direction</title>

<p>The initial release of DLM in uPortal 2.5.0 is DLM as used in Sungard SCT's Luminis product since 2002. For uPortal 2.6.0 focus will 

be placed on the 

following areas to enhance DLM. The information provided here represents the items that are anticipated to be 

for 2.6.0. Additionally, this information represents some intended designs. Such may change as implementation proceeds or 

requirements are clarified based in experience with the new pieces. If you have suggestions or questions on these items please share 

them on the uPortal email lists.  

</p>

<p><em>Fragment Manager</em></p>

<p>The dlm.xml file will be replaced with a Fragment Manager channel allowing fragments to be defined via the portal user interface. 

A mock-up of this fragment manager is as shown below. Most items currently configured using the dlm.xml file are visible. For example, 

precedence is a point value for fragments but even when two fragments are given an equal precedence, DLM then drops back to the 

ordering in dlm.xml with the first fragment of these two encountered during loading interpreted as having the higher precedence. So 

ultimately, there 

is no such thing as equal precedence in DLM. One fragment has greater or lesser precedence than any other fragment. This is depicted 

within the Fragment Manager by the ordering of fragments from top the bottom. Up and down buttons in the Precedence column enable an 

administrator with proper permissions to adjust the precedences of fragments.

</p>

<p><image>fragmentMgr.jpg</image></p>

<p>The name of each fragment corresponds to the "name" attribute of the &lt;dlm:fragment> element. The magnifying glass button to the 

right of the Precedence column allows a user with proper permission to view and edit the layout of a fragment. Each fragment's layout 

will be protected by a layout editing permission. If a user is granted that permission then they will be able to use the fragment 

manager but will only see those fragments for which they have permission. The delete button is for deleting a fragment. The edit 

button immediately to the left of the fragment name allows an administrator to change the name and type of the fragment.

</p>

<p>DLM does not currently support "pulled" fragments, fragments that users can subscribe to. As can be seen this capability will be 

added. Both pushed and pulled fragments will be shown in the same view in the Fragment Manager. This is important since each type 

can restrict movement of tabs and hence those tabs may be competing for location in a user's layout. The ordering here with respect 

to each other clearly shows which will have greater precedence when competing in a user's layout.

</p>

<p> 

The edit button to the right of the Type column will delegate over to a new channel being created as part of the permissions 

effort also under way for 2.6.0. Note the complex boolean expressions based on both user attributes and group membership constructs. 

Such will be the anticipated capability of the new permissions functionality. It is also anticipated that there will be a direct 

migration path for the constructs currently supported in dlm.xml by the currently defined set of evaluator factories.

</p>

<p><em>Pulled Fragments</em></p>

<p>As noted in the mock view of the Fragment Manager, pulled fragment support will be added. The audience specified for pulled 

fragments is the set of users who will have that fragment show up in the list of fragments that they can subscribe to from within their 

preferences area via a new link added for that purpose. The list of available fragments will be provided by a new channel that is 

brought into focus mode by selecting that link. Once a fragment is selected the focus will return to the preferences area and that 

fragment's tabs will be included at that time.

</p>

<p><em>Integrated Modes</em></p>

<p>This is a challenging area to define not because integrated modes is challenging but due to different groups of people having 

different perspectives on the easy of use of difficulty of use of integrated modes. Currently, DLM uses the preferences channel. 

It seems that the best approach would be to offer both the preferences channel and integrated modes support and let either 

institutions determine which will be used or allow users to select the one that works best for them. So more work will be done here 

to determine which route should be taken.

</p>

</section>



</content>