Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.
The built-in content modules in Sitefinity are the backbone of many projects. That’s why we’ve included a lot of functionality in them that you can use out of the box. Examples of this are paging and filtering on public pages. In some tricky scenarios, those features might not behave like you expect them to with their default configuration. This blog post tries to explain how paging and filtering through the URL works in all built-in content widgets.
From the first line of Sitefinity code that was written, we made the decision to avoid postbacks alltogether, and use AJAX and redirects instead. Unlike in 3.X, all the user interface now either redirects to a different URL or fetches data asynchronously. This includes public widgets. We’ll take paging of items in the News module as an example.
When you have a good number of news items, they are not all shown at once in the public News widget. It has a default page size setting of 20.
In the frontend, this setting displays links to change between the pages on the bottom of the news item list. Notice that when you click a different page, the URL is changed to contain the page number, and the browser does a redirect.
This redirect has several advantages:
If we had used a postback here, we wouldn’t have any of the above. The URL would stay the same.
Another case where this behavior of the News Widget is also present is filtering by taxon (categories or tags). In the screenshot below, I have created two categories and put a Categories widget on the page. Clicking the business category will filter all news items and only show those associated with the “business” category. Notice the URL is changed again.
As long as we have such a URL, the news widget will know that it has to filter items. Having the list of filtered items, we might again decide to page through them and click the link for the second page. In this case, however, the result may surprise us. Clicking the pager changes the URL, but removes the category filter. With this setup, there is no way to page through a filtered list of news items.
The reason for this behavior is that the page does not keep any state. Keeping any state would mean using postbacks and showing different content for the same URL. In this case, search engines will index only the initial version of our page. The nature of the HTTP protocol is stateless and search engines embrace the HTTP protocol. So if we want to do SEO, keep our page rank high, and please search engines, we need to provide different URLs for different content.
With our specific example, this means that both the page number and the category we filter by, have to be present in the URL. If we work with this constraint, we have several options for the URLs:
The problem with both of those is that slashes usually represent hierarchical structure and going deeper into the site. This means we don’t have a fixed URL structure and customers visiting our site may get confused. Also, if we want to support both of the above, the problem of parsing and retrieving information from that URL becomes much harder. We need to go through segments, decide which ones are related and what their order is. On the other hand, if we want a fixed order, we need to configure our widgets somehow to tell them whether the page goes first, or the category.
This scenario complicates things quite a bit, and this is the reason that Sitefinity does not support filtering by multiple parameters in the root URL. Instead, we’ve decided to use the query string for the purpose.
The query string is the part of the URL that is separated from the core part by a question mark. In that part, we can pass name-value pairs to the page. This gives us a chance to resolve our hard URL parsing problems, because now we have a way of naming our parameters. We can know which parameter is for paging and which is for filtering.
To instruct Sitefinity to use the query string, we need to set a property of all widgets that take part in the process. The property we have to set is called UrlEvaluationMode and is in the advanced section of the widget designers.
Once we change the value of that property to “QueryString”, all widgets will generate URLs accordingly. Here is what our URL would be, if we want to display the second page of a news item list, filtered by the business category:
In this evaluation mode, each parameter that we want to filter by will be added by its name (page, taxon, etc.). These URLs are ugly, but they give us a lot more flexibility when we have complicated scenarios. They are also unique, so all our content is indexed by search engines. One thing to note is that the UrlEvaluationMode property is applied globally to all widgets on the page. We cannot have two content widgets working in two different modes. If we want events to display their page in the URL and news to use the query string, we need to put them on different pages.
The parameters that have built-in evaluators in Sitefinity are:
We can have each of those in the URL at the same time, and the content widgets will work by applying the correct behavior according to each parameter.
These advanced options allow site owners to achieve a lot with the built-in Sitefinity modules, and still optimize their sites for search engines. In a future blog post, we will take a look at even more advanced scenarios with several widgets per page. Happy filtering and optimizing.
View all posts from The Progress Guys on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.