Portal Data Tables
  • 12 Sep 2024
  • 10 minute read
  • Dark
    Light
  • PDF

Portal Data Tables

  • Dark
    Light
  • PDF

Article summary

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

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.

blobid0__2_.png

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.

blobid3.png

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.

blobid4.png

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.

blobid5.png

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. 

blobid6.png

The Liquid looping syntax can also be viewed in the source code. The table will include all exports from the portal query.

blobid7.png

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:

mceclip0__14_.png

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.

blobid9.png

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&amp;id={{item.id}}" href="#" onclick="return (FW.Lazy.Popup(this, {width: '500px'}));">
        {{item.name}}
    </a>
</td>

blobid8.png

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

  1. Select New Method.

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

  3. Click Save.

  4. Click Create New Query.

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

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

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

      data_table_sql_filter.png
      In this case, the [record] on [test] is the [person] on the [application] table. The filter has been updated to make the appropriate connections.

  8. Click Edit Parameters.

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

  1. Select the appropriate view.

  2. Add a static content block from the portal builder palette.

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

part.png

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.

Sortable Table Headers

Source Code for Sortable TAble Class

<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

The table class searchable adds a search bar to the table, allowing portal users to search any text appearing within the table.

Searchable Table Class

data-search-text can also be added to display instructions or additional information in the search box.

<table class="table searchable" data-search-text="Search Records...">

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.

Nohighlight Table Class

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

Table with Different Table Row Classes

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.

Query Export Used in Table Row Class


Was this article helpful?