Adding tabs to a portal can help improve user experience by dividing information displayed in a portal into different sections and reducing scrolling. A portal with tabs typically consists of a default view containing the tab menu items and JavaScript, plus multiple additional views for the content under each tab.

Each tab will have an associated portal method where the action of that method corresponds to the data-tab HTML attribute in the Default view source code.

There are five steps (outlined in detail in the following sections) involved in creating portal tabs: 

 Step One: Creating the Default View

A portal with tabs will have multiple views. The default view will contain the necessary source code to generate the tabs. 

Sub-Tabs Class

This is the source code for an example default view with three tabs.

<ul class="subtabs">
<li>
<a href="#" data-tab="home">Home</a>
</li>
<li>
<a href="#" data-tab="profile">Profile</a>
</li>
<li>
<a href="#" data-tab="directory">Directory</a>
</li>
</ul>      

The subtabs HTML class allows the "tab" elements (i.e., the list items) to have an inline display.

The static content will not display "tabs" when administratively editing the view. Instead, it will show a bullet list.

Logged-in users will see the formatted tabs instead of the unordered list elements since Slate's CSS has specific styles for the subtabs class, which will render when viewing the page.

Step Two: Adding the data-tab Attribute

In the source code, you'll see that each item has a data-tab HTML attribute. The data-tab HTML attributes must match exactly the actions used in the methods.

In this example, the portal expects to have three methods, one with an action of "home", one with an action of "profile", and one with an action of "directory."

Step Three: Adding JavaScript

When the portal page is rendered, JavaScript asynchronously loads the content in the tabs via the FW.Lazy.Fetch function.FW.Lazy.Fetch is part of Slate's own JavaScript libraries. You should place this JavaScript code after the closing  tag.

Each tab's state is added to the browser history to ensure consistent navigation when using the "Back" button in the browser.

The content_body div will display the content of the view associated with the tab. For example, clicking on the "Profile" link will call the method with the action of "profile", and the div will display the content from the view associated with that method.

The active class "highlights" the selected tab to indicate the tab the user is currently on.

Dynamic Version

For a dynamic version that passes the query string parameters from the portal into the tabs, use the following script instead of the one above.

<div id="content_body">
</div>
<script type="text/javascript">
/*<![CDATA[*/
var loadTab = function (tab, queryString, isBack) {
if (queryString) {
var qs = FW.decodeFormValues(queryString);
delete qs["tab"];
queryString = FW.encodeFormValues(qs);
queryString = queryString ? "&" + queryString : "";
}
if (!isBack) history.pushState(tab, null, "?tab=" + tab + queryString);
$("a[data-tab]").removeClass("active");
$("a[data-tab='" + tab + "']").addClass("active");
FW.Lazy.Fetch("?cmd=" + tab + queryString, $("#content_body"));
};

window.addEventListener("popstate", function (e) {
if (e.state) loadTab(e.state, location.search.substring(1), true);
else history.back();
});

$("a[data-tab]").on("click", function () {
loadTab($(this).data("tab"), location.search.substring(1));
return false;
});

var qs = FW.decodeFormValues(location.search.substring(1));
if (qs["tab"]) loadTab(qs["tab"], location.search.substring(1));
else {
var default_tab = $("ul.subtabs").find("li > a").eq(0).data("tab");
loadTab(default_tab, location.search.substring(1));
}
/*]]>*/</script>

 Creating Additional Views for Tabs

In addition to the Default view that contains the tab framework, the content of each tab will have its own view. The content in these views will only display when the portal user is on that tab. If there is content that should always appear, regardless of what tab the user is on, then you should add that content to the default view. 

If you are adding tabs to an existing portal, the "Move" button can assist with moving content to various new views. 

Tip

Most views for tab content will use the one-column layout, particularly if the default view is a two-column or another partitioned layout. Since the tab view is placed in the default view framework, consider how the portal should appear. For example, if the portal default view has social media feeds appearing on the right side for all tabs, the tab content views only have the left side of the screen.

Existing portal view layouts may need to be adjusted if you transition from a portal without tabs to a portal with tabs.

 

Step Four: Creating the Methods

A portal with tabs will also have multiple methods, many with actions. 

In this example, the Homepage method has no action, as it runs by default and loads the tabs. Then, depending on the tab the user is on, different methods are called. 

Step Five (Optional): Conditionally Display Tabs

You can wrap tabs in Liquid markup, so they display only under certain criteria.

For example, in an alumni interviewing portal, you might only want the Volunteers tab to display if the portal user has a role of "Captain."

The Liquid markup is placed around the <li> tags. Only if the logged-in user has a role of "Captain" will that tab appear. 

Here, the default method is associated with the volunteer information query, allowing access to the exports in the volunteer information query for use in Liquid markup or other merge fields. 

The query contains role information used in the Liquid markup shown earlier.