Tab-SubTab Functionality

Context

This is a feature that was demonstrated at the Unconference 2009 regarding tab and subtab layouts. This feature is in production at our school. To try it for yourself, tabTag-uportal-impl.patch and tabTag-uportal-war.patch were made against uPortal 3.1.4. You should be able to apply these to that release and see it in action out of the box. Please note that the tabs appear as an unstyled/unordered list. The functionality is in place, but no CSS has been applied to the markup.

The note below was sent to the uportal-dev list. It's copied below and gives a good overview of this feature.

Hi All,

There has been some discussion on the various uPortal boards about tab sub-tab implementation, and there was also a ticket added to JIRA outlining the need for this:

https://issues.jasig.org/browse/UP-2720

I'd like to discuss how we at the University of Illinois implemented a custom tab sub-tab implementation for our instance of uPortal 3.1.1, and solicit any feedback on the pros and cons of our approach, and determine if our solution would be helpful for any other institutions out there. If you are one of those instituions, or are just curious, please read on.

I will attempt to give a brief overview of the technical steps The University of Illinois took to incorporate tab sub-tab functionality into uPortal 3.1.1. It has served us well, and has been used in production on three different campuses for over 8 months now without any problems. It would be our hope that our solution may be of benefit for the community at large, or the uPortal product. With that being said, we are curious if our implementation would be helpful as an out of the box option? Maybe as an optional theme? Of course we make no claim that this solution is perfect, and there are drawbacks, ( it only goes two levels deep at the moment), so if there any questions, comments, or concerns about this approach, please let us know.

An example screenshot of our tab sub-tab implementation can be found here:

https://netfiles.uiuc.edu/dimpsey/www/portal/academics-records.png

In the above screenshot, there are 6 "tabs", ( My Classes, Registration, Records, Course Information, Majors and Minors, Resources ), within another "tab", ( Academics ). So essentially this is a "tab sub-tab" implementation. Note that this second row is not portlets, as it is in the default release of uPortal. ( We decided not to show that row in our release at Illinois, instead opting to show the portlets in the sidebar. ) But, it is also important to note that the portlet row, if opted for, would work fine with this navigational scheme.

The concept behind this multi-level navigation is really simple. It is based on the same idea of labeling email messages in gmail, or tagging bookmarks in delicious. We are simply labeling/tagging fragment-layouts/tabs and then aggregating all the tabs with the same label within the rendering pipeline via XSL.

Let me define some terms for clarification:

tabTag - the label or tag we will associate with a given <tab> element in a fragment layout.

tab - this term is exactly the same as it is currently understood -- as a tab in uPortal.

So lets take a look at that screenshot again, though this time it is annotated:

https://netfiles.uiuc.edu/dimpsey/www/portal/annotated-academics-records.png

Now using the new terminology, we can see we have 6 tabs "tagged" with the Academics tabTag. This tabTag is simply a folder structure attribute that is a child element of the <tab> element in a fragment layout file for these 6 tabs. The corresponding xml in the .fragment-layout file for the "Records" tab looks like this:

<tab unremovable="Y" immutable="N" hidden="N" name="Records">
    <structure-attribute type="folder">
      <name>tabTag</name>
      <value>Academics</value>
    </structure-attribute>

Using this system, all programming logic is confined to the structure and theme XSLs. There is not any need to change the database, nor is there any structural changes to the incoming struct xml ( i.e. another level of <folder>'s ). Programmatically it works like this:

1) All distinct tabTag attibutes at the tab folder level are identified in the incoming struct xml, and put into a list. This would be the first level of navigation.

2) The user selected tabTag is identified and is highlighted.

3) All tab folder elements with the selected tabTag attribute are identified and aggregated.

4) The selected tab is the activeTab.

As one can see this solution is for the most part non-invasive. The tabTags can be viewed as logical constructs that contain standard uPortal tabs. And since the tabs are just tabs, flyout navigation is not impacted, add a tab still works, move tab left and right still works.

As stated above, this solution works well for us at Illinois because of our needs. But this solution only goes to the second level of hierachy, and does not currently fill the description for n-levels, if that is what is desired.

Tim Carroll and I gave a presentation of this functionality at the San Diego conference. For more implementation and technical details, please see the following .ppt.

https://netfiles.uiuc.edu/dimpsey/www/portal/jasig_spring_2010_tabTags.ppt

And as stated above, please feel to state any questions, comments, or concerns.

Jeff Dimpsey

Research Programmer
The University of Illinois at Urbana-Champaign
dimpsey@illinois.edu