ALM Control URLs

Some schools have rewritten their themes to provide alternate interfaces for integratedModes and ALM by maintaining the format of the URLs but introducing tricks like AJAX, new controls, etc. This is a place to document these things.

Necessary Features

Add: Tab, Column, Channel
Move: Tab, Column, Channel (fragments?)
Remove: Tab, Column, Channel
Rename Tab
Minimize Channel

Some Initial Thoughts from Virginia Tech

A problem with OOB uPortal is the creation of new tabs. One must create a tab and then create a column (the non-trivial step) before adding any channels. For the My VT interface, the problem was compounded by the fact that we must create folder for the tab, a folder for the first page, and then a folder for the column which will contain channels. (more details about how we solved this for our users can be provided, but not necessary for this discussion)

A solution I've been bouncing around in my head is that of creating a customization API that exists independently of any rendering pipeline or UI. This API could be referenced from a Preferences portlet or from a customization servlet/JSP that can be tailored to an organization's theme/structure needs. This separate API could also allow layout management tools that lived outside of the portal UI. For example, command line tools that allowed manipulation/deletion/backup/restoration of users' layouts.

I know this is very rough, but I hope to give you an idea of how the API might work. While not represented here, a DOM-like API would probably be a good idea.

XMLDocument getLayout()
       void setLayout(XMLDocument)
       void saveLayout()
       Node getLayoutRoot()
       Node addFolder(name, parentNode, nextNode)
       Node addPortlet(fname, parentNode, nextNode)
       void setParameter(node, name, value[])
       void deleteParameter(node, name)

Modality

I don't really like the idea of save/set options, since I really think that the model should be non-modal. Right now there's this oddity of actions like remove channel which happen immediately, but other options which are applied and then saved. Getting users to save changes in particular seems like it's as hard as getting them to logout.

Looking at the example below for adding a tab, you'll see that the addTab method automatically saves the new tab when it is created. I think it should be up to the institution to decide how save should be implemented. Out of the box, all actions could be immediately saved. - Collier

So, for My VT, adding a tab might work like this:

Page HTML:

<a href="/customize?method=addTab&name=New+Tab">Add a Tab</a>

Note: For My VT, we always add tabs to the end, so we don't need to pass any next or parent parameters.

Customize Servlet: (in pseudocode)
Edit: Removed :: notation which was Virginia Tech-specific.

 
function addTab(name) {
  var root = getLayoutRoot();
  var newTab = addFolder("New Tab", root, null);
  var newPage = addFolder("default", newTab, null);
  var newMainColumn = addFolder("main", newPage, null);
  var newSideColumn = addFolder("side", newPage, null);
  saveLayout();
}

Which would create a layout like this:

 
<layout>
  <folder name="New Tab">
    <folder name="default">
      <folder name="main"/>
      <folder name="side"/>
    </folder>
  </folder>
</layout>

Things I'd like to see us move toward:

Having two "IDs" for folders/portlets, one that is human-readable and one that is generated by the system (database ID numbers).
The "name" of a folder being the display name of the folder, or moved into a parameter described in the next point.
```
<folder id="tab-home" name="Home" systemID="345-42"/>
```

I'd like to see arbitrary, multi-value parameters allowed for folders and portlets

<folder id="tab-home" systemID="345-42">
  <parameter name="display-name"><value>Home</value></parameter>
  <parameter name="type"><value>tab</value></parameter>
  <parameter name="allowed-portlet-widths">
    <value>30</value>
    <value>60</value>
  </parameter>
</folder>