Portal Tabs

Adding tabs to a portal can help improve user experience by dividing information displayed in a portal into different sections, as well as reducing scrolling. To add tabs, users will need to edit multiple parts of the portal.

Adding Tabs

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.

Example View with Three Tabs


If you are adding tabs to an existing portal, please note that you'll need to create a new default view with just the tab framework, and then make adjustments to your existing method, as the former default view and method (pre-tabs) will become a view associated with a tab method. For example, moving from a portal without tabs (one view, one method) to a portal with three tabs would result in four views (the tab framework default view and then the three views for the tab content) and four methods (one default and then three with actions for the three tabs).

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.

Users will need to follow these steps (outlined in detail in the following sections) to create tabs: 

  1. Create a Default View to add specific classes in the HTML source code.
  2. Within the source code, create links using specific data-tab HTML attributes. 
  3. Add Javascript below this HTML code to asynchronously load the tab content.
  4. Create/Edit Methods to have specific actions. 
  5. Use Liquid markup to conditionally display tabs (optional).
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. 

Portal with Multiple Views

Sub-Tabs Class

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

Portal Tab Source Code

<ul class="subtabs">


<a href="#" data-tab="home">Home</a>



<a href="#" data-tab="profile">Profile</a>



<a href="#" data-tab="directory">Directory</a>



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.

Admin Display of Portal Tabs in Content Block

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 actually viewing the page.

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."

Source Code Data Attributes for Tabs


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. This JavaScript code should be placed after the closing </ul> tag.

Source Code JavaScript for Tabs

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

window.addEventListener("popstate", function(e){
if (e.state) loadTab(e.state, true);
   else history.back();

$("a[data-tab]").on("click", function(){
return false;

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

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.

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 that content should be added 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. 

Move Button for Content Blocks in Portal Views

Move Content Block to a Different Portal View


Most views for tab content will use the one column layout, particularly if the default view is two column or another partitioned layout. Since the tab view is placed within the default view framework, be sure to 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.

Default Portal View the Tabs and Social Media Feeds

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

Creating the Methods

A portal with tabs will have multiple methods as well, 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. 

Portal Methods for Tabs


The action of the method must match exactly the data-tab HTML attribute.

Methods associated with tab views should use the "Output Type" of AJAX Popup/No Branding. Tab methods must use that output type for the content to display properly in its views.

Conditionally Display Tabs

Tabs can be wrapped 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."

Liquid Markup for Portal Tabs

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


The merge fields used in the Liquid markup must be in a query associated with the default method. This default view with the tabs will need the information in the query in order to properly evaluate the Liquid markup.

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. 

Portal Default Method

The query contains role information, which is then used in the Liquid markup shown earlier.

Query Associated with Portal Default Method

Was this article helpful?
10 out of 11 found this helpful