I am unfamiliar with opt-in tags, or do not know it by that name. What is the purpose of the functionality?
Actually, we do allow users to add their own tabs, but they do not have the capability to define their own tabTags, though we have this capability locked down by tabTag. To explain with an example, in the screenshot I provided, the user is not allowed to add any tabs under "Academics" tabTag. However, if a user clicks on the "My Home" tabTag, the customize menu in the left hand menu would have another option which would allow a user to add a tab which then would be displayed under the "My Home" tabTag. So in essence, the tabTags are defined by us as we import a fragment-layout file, but we have added functionality that allows tabs to be added under some tabTags, while other tabTags do not permit this. In other words, the default uPortal action of "Add a Tab" works with this tab-subtab solution, just as it works on default uPortal install. The .ppt that is included in the first email shows how this is done. To answer another question, I could envision a solution for a user to add a new tab, and a new associated tabTag at the same time. It is just a matter of specifying a corresponding structure attribute, ( the tabTag ), when creating a new tab. ( Of course, there would need to be some backend logic written to handle this request. ) On Sep 14, 2010, at 3:10 PM, Bruce Tong wrote: > That's a nice looking site; the subtags are pretty cool. > > Folks have asked for them here, so we're interested in the feature. I > also am anticipating making heavy use of opt-in tags, which I > understand is an up-coming feature perhaps known under a different > name. How would those two features work together? Would there be > anything that would prevent me from defining an opt-in tag with > subtags? > > It doesn't look like you let users add their own tags. Would there be > any complications in that area? If users could add their own tags, > could they add their own subtags? > > On Tue, Sep 14, 2010 at 2:05 PM, Dimpsey, Jeffrey Scott > <[email protected]> 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]> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> > > > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
