This month I’m continuing my series on looking at how functionality is built into the new templates available for Power Pages. In this post I am looking at the Program Registration template, which allows users to browse and sign up for classes, and is useful in scenarios such as an after school program. Specifically, I’m going to look at the functionality that allows users to search through the available classes.
The home page of the program registration page offers the user the ability to search through the available classes. You can search by keywork, or filter using dropdowns like category, season, level and type.
Each time you select new filter criteria, the page refreshes, and classes that match that criteria are shown. You can search using keywords, or using one or more dropdowns, but you can’t mix those two.
We know the search functionality exists on the home page of the site. However, this doesn’t tell us exactly where the code is – instead, it just tells us where to start looking.
Unless the code is common across the whole site, in which case it might appear in the header or footer, the first place to look is on the web page record itself. While I like to use the Portal Code Editor in the XrmToolBox, you can also look around the Portal Management App (or the new Power Pages Management app, if you’re using the enhanced data model), or in the design studio using the VS Code for Web extension in the Power Pages Design Studio.
The copy attribute contains some HTML markup, but also has some Liquid include statements, which means it is bringing in additional code from Web Templates – in this case called “Portal Web API Wrapper”, “Drowdown Filters” and “Course Catalog”.
The main chunk of code to look at is the onchange event for the filter inputs, starting at line 26.
This is what causes the page to reload each time a new filter is selected.
With the page refreshing with the new query string parameters, we can now look at the Course Catalog web template to see how they achieved the filtering itself. There, you’ll see a large FetchXML query crafted, with conditional Liquid statements including certain filters based on the query string parameters. So, if for example the Category query string is present, filters are added to the FetchXML query to only get results that match that category.
Once the FetchXML query is executed, a loop is performed to display the results.
Since the page reloads each time, the browser history gets updated for each search. This allows a user to go back and forwards between their searches. I think that is a good user experience.
Overall, if you need a quick search interface, this will get the job done. But with a bit more custom code, you can achieve a more user-friendly search interface.