- 12 Sep 2024
- 10 minute read
- Print
- DarkLight
- PDF
Portal Data Tables
- Updated 12 Sep 2024
- 10 minute read
- Print
- DarkLight
- PDF
Data tables in portals allow users to display query data in a familiar, user-friendly manner. These tables are typically used to show one-to-many relationship data. For example, an applicant might have multiple test scores that should be displayed on the status portal or an alumni volunteer might have multiple interviewees assigned to them.
This article covers two methods of creating tables in portals: the table widget and liquid looping. The table widget method is more straightforward and user-friendly, while the liquid looping method provides additional options for more advanced users. Regardless of the method used, a query needs to be added to your portal to capture and display the desired data; this query is constructed the same for both methods.
Table Widget Method Prerequisites
Liquid Looping Method Prerequisites
Basic HTML (specifically
<table>
,<tr>
, and<td>
tags)
Create the Portal Query
Before proceeding with either method to create tables in your portal, create a new query in your portal. The query must have an output node. A node can be added by clicking "Edit Parameters" in the portal query.
In this example, the query is pulling a list of prospects, and the results set from the query will be placed into the node of "person_list."
⭐ Tip!
Remember to include a "Sort" option to determine the order in which the results should appear.
Table Widget Method
⚠️ IMPORTANT!
Only one table view widget can be used per view. For views with multiple tables, use the Liquid Looping method below.
In a portal view, click and drag from the palette to add a new Table View widget.
The widget contains general settings for configuring the table view, a Page Display section that determines how the widget should render within the portal view, and a Table Layout section where the table contents are formatted.
Give the table a Name, and set the status to Active. Then, select a portal query to populate the table results.
Important!
Only portal queries that have a node will appear in the dropdown list of queries to select.
The Items per page field lets you set the number of results that should appear per page. The table view includes pagination with "Prev" and "Next" links, and so each page will contain a maximum number of rows based on the entered value. If no Items per page is set, it will default to 50.
Clicking "Generate Template" will add the table as well as the basics of the Liquid markup and looping that can be further edited if necessary.
The Page Display determines what appears as the header text, if desired, and any message that should appear if there are no results in the table.
This default Liquid markup conditionally displays the text "No data was found" if the size of the node is not greater than 0 (i.e. no results are returned).
In the Page Display source code, JavaScript is generated automatically that will render the table on the portal page.
In Table Layout, the generated table uses the names of the exports in the query as column headers. Table Layout also shows the Liquid markup generated that conditionally displays the "Prev" and "Next" links based on the number of results. For example, if there are no additional results after the current page, the "Next" link will not appear.
The Liquid looping syntax can also be viewed in the source code. The table will include all exports from the portal query.
The merge fields in particular will reflect the order of the exports in the query as well. The columns can be edited or removed as desired.
The end result in this example would look as follows:
If, after testing, you wish to make changes to the table, or if additional exports were added to the query and you would like those new exports included in the table, the table template can be reset by editing the table and clicking "Reset Template." Alternatively, the table can also be directly edited in the Table Layout to add the new exports.
Pop-up Functionality
Portal pop-up functionality is often added to display additional information about a particular row in the results list. When using the Table View widget, a link to a pop-up is automatically generated within the table if the query used contains the exports of "id" and "name".
<td>
<a data-href="?cmd=details&id={{item.id}}" href="#" onclick="return (FW.Lazy.Popup(this, {width: '500px'}));">
{{item.name}}
</a>
</td>
More specifically, both "id" and "name" will be referenced within the same table cell, and the link itself is associated with a portal pop-up method that has an Action of "details." When the table is rendered on a portal page, each table row can then display a pop-up when clicking anywhere on that row.
If the method in the portal has a different Action, the source code can be edited to match the desired method.
🙈 Don’t see the pop-up links?
Only portal queries that have exports with the labels id and name will generate this link. In a Configurable Joins query, these exports will default to the names ‘Person GUID’ and ‘Person Name’, respectively. If these two exports are not added to your query, or do not have the correct labels, the link must be added manually.
Liquid Looping Method
Using Liquid looping, it’s possible to add multiple data tables to the same portal view.
Step 1: Create the Method
Select New Method.
Enter the following Method configurations:
Status - Set the status to Active.
Name - Provide a descriptive name, such as Test Score Table.
Type - Set the type to GET.
View - Select the Application Status Page.
Output Type - Set the output type to Default Branding.
Click Save.
Click Create New Query.
Enter the following Query configurations:
Name - Provide a descriptive name, such as Test Scores.
Population - The query base should be the item to be displayed. For this example, select the Test Scores query base to pull one row per test score.
Add exports
Add the exports to be used as merge fields in the Portal View. We recommend updating the export label to be lowercase and use underscores instead of spaces.
Add Filters
Test Status - Include the Test Status to display verified test scores received.
Portal Identity - When using a query base that is not Applications for the Applicant Status Portal, the Portal Identity filter will need to be adjusted.
In this case, the [record] on [test] is the [person] on the [application] table. The filter has been updated to make the appropriate connections.Click Edit Parameters.
This query must have a value for Output Node. We recommend naming it something intuitive. For example, if displaying a list of test scores, call the node test_scores.
Step 2: Add merge Fields to the View
Add the merge fields to the Portal View using Liquid looping.
Select the appropriate view.
Add a static content block from the portal builder palette.
Build a table with columns for the different data points to be displayed.
In the Source code, add in Liquid markup to loop through the results (as in the example below).
Note how the Liquid markup refers to the node of the Portal Query and each merge field is prefixed with "result."
<tbody> {% for result in test_scores %} <tr> <td>{{result.test_date}}</td> <td>{{result.test_type}}</td> <td>{{result.test_total}}</td> </tr> {%endfor%} </tbody>
If only displaying verified test scores, we recommend using the 'Has Verified Test Score' filter to only show this table to applicants with verified test scores to display.
Additional Customization via CSS Classes
When creating tables using HTML in portals, various table classes and table row classes can be leveraged to allow for a variety of functionality and design aesthetics.
Classes can be either predefined within Slate, like the following table classes, or they can be custom, such as creating custom classes specific to your institution. When an HTML element is given a Slate predefined class, a class defined in your branding, or a custom class defined in your portal, that attribute will inherit the style of the specified class.
Table Classes
Table classes can be used to adjust the display and functionality of a table.
sortable
If the headers in a table should allow the portal user to sort the data displayed, a class of "sortable" can be used.
<table class ="table sortable">
Tip
If the table is leveraging the Table View Widget, the headers will only sort the data appearing on that page of table. It will not sort all paginated results.
searchable and data-search-text
nohighlight
Typically, if a column in a table row is a link, the entire row becomes a link, allowing the portal user to click anywhere on the row to open the link. However, there may be cases where the desired behavior is to have just a single column be linkable. The table class of "nohighlight" allows for just the columns with links to be linkable.
<table class="table nohighlight">
In this example, only the second column is a link, rather than the entire table row.
Tip
The above table classes can be combined together to have a table that is both sortable and searchable, sortable and nohighlight, or all three together.
<table class="table sortable searchable nohighlight">
Table Row Classes
Table row classes can be used to adjust the display of specific table rows. Using Liquid markup, certain rows can be displayed differently based on certain criteria.
For example, in a table of applicants, the portal user may wish to see admits highlighted in green and denied applicants highlighted in red.
Creating the Table Row Classes
In order to conditionally change the display of a table row, different table row classes will need to be set.
To create different background colors (or other stylings), <style> tags can be added. In the code below, a table row (tr) with the class admit
will have a green background and those rows with the class deny
will have a red background.
Further down, a merge field is leveraged to determine the class.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<style type="text/css">
/*<![CDATA[*/
tr.Admit {background-color: green; }
tr.Deny {background-color: red; }/*]]>*/
</style>
</head>
<body>
<table class="table searchable sortable nohighlight">
<colgroup>
<col />
<col />
<col />
</colgroup>
<thead>
<tr class="column">
<th>Person Name</th>
<th>Person Major</th>
<th>Person Decision</th>
</tr>
</thead>
<tbody>
{% for item in applications %}
<tr class="{{item.decision}}">
<td>{{item.name}}</td>
<td><a href="LINK HERE" target="_blank">{{item.major}}</a></td>
<td>{{item.decision}}</td>
</tr>
{% endfor %}
</tbody>
</table>
</body>
</html>
Adding the Query Export to be Used as a Table Row Class Merge Field
As referenced earlier, a merge field is used to set the class. This merge field must be an export in the associated query. In the example, the merge field is {{item.decision}}
, where item is the Liquid looping prefix, as determined by {% for item in applications %}
, and decision is the export label in the query.