Portal Pop-ups

Pop-ups in portals can provide users with additional information without crowding or cluttering up the main portal page.

Typically, pop-ups are leveraged by clicking on an individual result within a list or table of records. A table cell can function as an anchor element which, upon clicking, runs a function that brings up a pop-up.

The link to the pop-up consists of a custom link that indicates the the portal method to call, and any additional parameters needed to complete the action, for example an indication of the record clicked.

In order to make a pop-up, you will need:

  • a query to pull the data to be displayed in the pop-up
  • a view to display the data from the query
  • a portal method to tie everything together
  • a link that triggers the pop-up to show in the portal
Create the Pop-up Query with Parameters

A pop-up will have a query that determines the information to display. This query will typically have a parameter and a custom SQL snippet filter to ensure that the data returned in the pop-up belongs to the record or item clicked on in the main view.

In cases where the information in the pop-up will be based on the person/dataset/application record, the parameter will be the ID of that record, which is a GUID.

Parameters are added in the "Edit Parameters" pop-up. You will need to add <param /> syntax and indicate the type of data being passed in, such as a uniqueidentifier or string. GUIDs, such as a person ID, will be a type of uniqueidentifier.

Edit Query Parameters

  Node vs. No Node

If the query is meant to return a set of results, such as a list of athletes, you'll want to give the query a node so that you can loop through the results to build out your view using Liquid Looping.

If the query is going to return results for just a single record, like in a pop-up, the query should not have a node.

In this example, the query is returning data for only the clicked record. As such, there is no node.

Adding a parameter allows the parameter to be used in a custom SQL snippet filter.

Custom SQL Filter

In this example, the query will pull data for the person where the person ID is equal to the ID of the record clicked on in the portal.

  Why p.[id]?

In this example, the query base is Person and the query base key is p.[id]. If the portal uses a different query base, such as Applications, the portal may be referencing different records and matching on different IDs. For instance, if the portal displays application records and clicking on a record should return a pop-up with details about a particular application, the filter may be (a.[id] = @id). Configurable joins queries can also use the GUID filters, rather than custom SQL, and enter @id in the filter.

Configurable Joins GUID Filter

In other portals, such as the Athletics Portal, you may see @sport_id = sp.[id] or other parameters and IDs. It is important to consider what query base you are using and what record (person, application, sport, etc.) is the base for the pop-up information.

Designing the Pop-up

The layout and content of a portal is defined in a separate view. Typically, additional information is displayed in table layout.

Portal Pop-Up View

The source code of a pop-up view might contain additional syntax, such as form methods and hidden values. This additional syntax is needed for pop-ups associated with POST methods.

Source Code of Pop-Up View

For example, a pop-up in an athletics portal that allows the user to save or update a rating will have a form method attribute of "post", a form action, and hidden values included so that they can be referenced in POST queries to update the appropriate record and information.

  Need help adding a close button?

Learn more about designing portal pop-ups!

Add the Pop-Up Method

A pop-up will have its own method, associated with a view and at least one query. This method will combine the query and view created in the previous steps.

The portal method to display a popup will have a type of GET, an action label, an output type of "AJAX Popup/No Branding," and be configured to use the appropriate view. The action must be unique within the portal.

Portal Pop-Up Method

Finally, the portal method will also needed to be linked to the query or queries necessary to populate the view with data.

Update the View to Link to the Pop-up

The list of results on the main portal view will need to be updated to now link to this new popup.

This is done in the source code of the view part where the list or table of records is constructed.

{% for person in persons %}
<tr>
<td>
<a data-href="?cmd=detail&amp;id={{person.id}}" href="#"
onclick="return (FW.Lazy.Popup(this, {width: '500px'}));">{{person.name}}</a>
<td>
</tr>
{% endfor %}

Typically, the attributes of the anchor tag as defined in the first cell of each table row will be inherited by all cells in that row, thus making the whole row display the popup upon clicking.

The cmd parameter in data-href should match the action from the method. If the action on the method is "detail", the cmd should be detail.

In this example, the {{person.name}} merge field is turned into a link to the pop-up. Clicking the link calls the "detail" portal method and passes in the {{person.id}} value as the id parameter.

  Why id={{person.id}} and not just {{id}}?

In this example, the portal is returning a results set from the "person" node. To do so, the portal leverage Liquid looping. Since the loop begins with "for person in persons", all merge fields are prefixed with "person". In order to return the appropriate id for each row, the merge field is {{person.id}}. In other Liquid looping, you may see "for result in node" or "for item in node." Whatever syntax is used, that prefix (result, item, person, etc.) must be used for the merge fields. 

Note that the "id" export must be included in the portal query, even if the value is not being displayed to the portal user. If the export for the merge field is not included, no parameter will be passed into the pop-up portal query, and the portal will not be able to return the information for the record clicked.

Unlike other links that may appear in portals, such as links to forms, the anchor element uses the Slate JavaScript function FW.Lazy.Popup() to define the popup. The first part of the onclick syntax defines what URL the pop-up should try to load - in the example above, it is the current element for which there is a data-href attribute that contains the URL. The second parameter is a JSON string that defines attributes of how the pop-up should be displayed, in this case, its width.

Was this article helpful?
3 out of 6 found this helpful