Sorry for taking so long to reply to this. It seems like a great feature and a very good way to to implement it without causing breakage to existing layouts. I'd be very interested in seeing a patch against 3.1 to get a better idea about of the code changes. Once we have that we can work on getting it into trunk and seeing if we can include it in a patch release.

-Eric

On 9/14/10 1:05 PM, Dimpsey, Jeffrey Scott wrote:
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
[email protected]<mailto:[email protected]>


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to