Prior to the Portal Editor and Application Status Portals, many application status pages and custom portals were built using eXtensible Stylesheet Language Transformation (XSLT) files. These portals must be migrated to Views in the Portal Editor to ensure the sustainability of the portal by improving transparency and ease of maintenance.

Tip

If you'd rather start fresh, you can use Suitcase to quickly and easily import a standard application status portal.

XSLT Portals

An XSLT portal uses XSLT files to design and display data. Editing XSLT files typically requires understanding of HTML and XML, which many users may not know. As such, maintaining and updating these portals can become burdensome.

To determine if your institution has portals using XSLT, look in:

• Database > File Editor, where most of the older Application Status Page XSLT files are found

- OR - 

• The files found under the Edit XSLT button in the Portal Editor (Portals using Views will not have this button)

Application Status Page XSLT

If your institution customized the Application Status Page XSLT file, these customizations were made either using:

• Application Editor > Status > General Settings

- OR -

• By creating Teasers or Page Keys and then editing the /apply/status.xslt file directly

  • Teasers and Page Keys are no longer necessary with portal views. Views can filter both widgets and static content, and static content allows for merge fields.

  • Teasers and static content don't have to undergo a one-to-one replacement. Many teasers can be consolidated into one or just a few static content blocks with merge fields.

Other Portals

Institutions may have older XSLT versions of standard portals, such as an Athletics or Alumni Interviewing portal. These can be imported via Briefcase. We recommend adding the portal that most closely resembles your portal and editing the portal from there. 

As you review your portals, if there are any queries using custom SQL, we recommend investigating any custom SQL queries to see if they can be recreated using the standard Query interface. Custom SQL should only be used when necessary (such as for queries associated with POST methods).

Building the Portal

After reviewing the documentation, start building out the portal queries and views, as well as the methods to connect the portal together.

Create a new portal, rather than editing the existing one.

After building out the framework for the new portal, we recommend impersonating an applicant, user, or dataset record with the original portal on one window or screen, and impersonating with the new portal on another. This will help you conduct a side-by-side comparison.

Tip

You don't need to know or understand every line of an XSLT file to create a new View-based portal. Use this rebuilding opportunity to enhance, update, or even re-imagine the portal so that it functions best for your process. 

Testing

Testing any portal, whether it is a new portal or an update to an existing one, is crucial. Go through every step of the process in the new portal to ensure that the functionality is as you need.

For applicant status portals, impersonate applicants at all stages of the process (such as a current applicant with no decision, an admitted applicant, and a denied applicant). Additionally, take a test applicant through the entire decision release process, and review what the applicant sees at every stage.

For alumni interviewing portals, test assigning (for captain-based portals), claiming, and unassigning interviewees, as well as filing interview reports. For captain-based portals, also ensure that you test all of the various roles (such as Captain, Volunteer, and Interview Coordinator).

For athletics portals, impersonate various coaches and roles, and save and update ratings.

Transitioning to the New Portal

The transition process for the new portal depends on the type of portal.

Applicants can transition from using the XSLT-based status page to the new applicant status portal by updating the period or round to use the new custom portal.

For other portals, rather than needing to communicate a new URL to all users, you can update the portal key of the original portal to something different, and then update the new portal to use the original portal's key.

Example

• Original portal key: athletics

• New portal key: athletics_new

<Building and Testing Period>

• Update original portal key: athletics-archived

• Update new portal key: athletics 

In this example, coaches would continue to go to /portal/athletics, but the portal would be the new portal, rather than the original one.