|
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:
Five steps to creating a portal with tabs:
- Create a Default View to add specific classes in the HTML source code.
- Within the source code, create links using specific data-tab HTML attributes.
- Add Javascript below this HTML code to asynchronously load the tab content.
- Create/Edit Methods to have specific actions.
- Optional: Use Liquid markup to display tabs conditionally.
Adding tabs to an existing portal?
You must create a new default view containing only the tab framework, then make adjustments to your existing method. 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, plus the three views for the tab content) and four methods (one default, plus three with actions for the three 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.
|
|
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 </ul> 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. |
 |
<div id="content_body">
</div>
<script type="text/javascript">
/*<![CDATA[*/
var loadTab=function(tab, isBack){
if (!isBack) history.pushState(tab, null, "?tab=" + tab);
$("a[data-tab]").removeClass("active");
$("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(){
loadTab($(this).data("tab"));
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");
loadTab(default_tab);
}
/*]]>*/</script>
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. |
 |
Important!
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 appropriately in its views.
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. |
 |
Important!
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 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. |
|
|
The query contains role information used in the Liquid markup shown earlier. |
|
