This article helps you identify deprecated XSLT (Extensible Stylesheet Language Transformation) build files in your database, interpret their contents, and transition to custom application pages.

A brief history of XSLT build files

Before 2021, if Slate users wanted to customize standard pages of the Slate-hosted application with custom questions and static page elements, they’d create XSLT build files.

Now, creating custom application content is more user-friendly. If you need to add something to one of the standard application pages, you can recreate the page as a custom Slate-hosted-application-scoped form in the form builder.

We offer step-by-step instructions to creating these pages in the articles in this section. Some articles feature ready-made replacements that you can import with Suitcase.

As you identify the pages in your own application that are hosted on build files, refer to the other articles in this section to learn how to recreate that page as a form.

📖 Further reading: Custom application pages overview

How XSLT build files may appear in your database

Depending on the age of your database, XSLT build files might exist in your database in one of two configurations:

• In the Application Editor as part of a standard page

• In the Application Editor as a Custom App Page (special use only)

One or both of these may be present in your database, and we show you how to identify and replace both types in this article.

XSLT build files for standard application pages

We first want to identify any active build files in a familiar context: the Application Editor.

Identifying build files in the Application Editor

In Database → Application Editor, select an application.

We focus our attention on the standard page modules, identifiable by their part ID:

• per: Personal Information

• aca: School History

• act: Activities

• job: Employment History

• ref: Recommendations

• tes: Test Scores

Select one of these pages to view its configuration.

If the page has any XSLT build files that map custom fields (more on this below), they appear in a section with a name ending in -build.xslt.

The objects that appear in this list represent the custom fields mapped to the application page’s build file. These custom fields must be recreated in the custom Slate-hosted-application-scoped form that replaces the standard application page.

📝 Note: This list is not exhaustive. Your application page may be associated with XSLT build files that include only static elements or conditional logic, which don’t appear in this list. To locate these files, we’ll head to Database → Files, covered in the next section.

Locating build files in Files

Now that we have a sense for which of our application pages have XSLT build files, we can work toward replacing them.

In Database → Files, select the apply directory, then enter build in the search bar.

All build files follow the naming convention /apply/YOUR-APPLICATION/APPLICATION-PART-build.xslt.

Build files located in the /apply/ directory apply to the corresponding module in all application bases, unless a more specific file exists.

📝 Note

It was once a common practice to assign an invalid name or path to a build file as a way to deactivate it. For example: /apply/per-build-ThisFileIsInactive.xslt, or /apply/INACTIVE/per-build.xslt, where no application base uses the path INACTIVE. Files with these invalid conventions aren’t in use by the application and can be deleted.

▶️ Action items

1. Using the following table, for each standard page with custom fields in the build.xslt section, recreate that page using a Slate-hosted-application-page-scoped form. Include the custom fields you found in the Application Editor in the new forms.

   Part ID	Module Description	Build File Name	Instructions to replace
   per	Personal Information	per-build.xslt	Custom personal background page
   aca	School History	aca-build.xslt	Custom school history page
   act	Activities	act-build.xslt	Custom interest page
   job	Employment History	job-build.xslt	Custom employment history page
   ref	Recommendations	ref-build.xslt	Custom reference page
   tes	Test Scores	tes-build.xslt	See A Note on the tes Page

2. Once a build file has been migrated to forms or is determined to not be in use, select the file and select Delete.

A note on the tes page

Among the standard application pages, tes is somewhat unique: the widget on this page that lets applicants choose a test type and enter their scores cannot currently be replaced by a Slate-hosted-application-scoped form.

If your tes page is associated with an XSLT build file, the file modifies the tes page in one of two ways, which determines your course of action:

• The XSLT build files include person- or application-scoped fields: These must be recreated in Slate-hosted-application-scoped forms, either on an existing page in the application or by creating a new page and adding them there.

• The XSLT build files modifies the test widget itself: In this case, Technolutions staff will review your case and reach out to your team to collaborate on a migration plan.

XSLT build files with Custom App Page configuration

You may find files that use the deprecated configuration Custom App Page (special use only).

This configuration, which was deprecated over ten years ago, predates the adding custom forms to the application as pages. All XSLT-based application pages with this configuration must migrate to custom application pages made with forms.

Identifying custom app pages in the Application Editor

In Database → Application Editor, select an application.

From the list, identify any page with a Part ID starting with app? and a Module Description Custom App Page (special use only). For example, app?familyinfo, or app?interests.

Select one of these pages to view its configuration.

A section with a name ending in .xslt includes the build files (if any) currently associated with the page.

📝 Note: This list displays the custom fields mapped on the build file. However, this functionality has been long deprecated, and in some cases these elements will not appear even if they exist. To review contents fully, the file itself must be accessed directly, in Database → Files, covered in the next section.

Locating custom app page files in Files

In Database → Files, select the apply directory.

All custom app page XSLT build files follow the naming convention app_,  and have a file type .xslt.

To narrow the list to only custom app page files:

1. Select the Customize View icon.

2. Select Copy.

3. Enter a name for the view, like XSLT file search.

4. Select Subquery Filter.

5. Configure the following settings:

   • Name: Enter a name

   • Type: Dependent subquery

   • Aggregate: Formula

   • Formula: Enter @File-Path LIKE '/apply/%app[_]%.xslt'

     

6. Select Save.

This search returns XSLT files on any path that follows the app_ naming convention. For example:

▶️ Action items

1. For each Custom App Page (special use only) page you identify, recreate that page as a form, making sure to include custom fields you found associated with the page in the Application Editor.

2. Once all pages have been migrated to forms, select the file and delete.