URL Filtering with Multiple Content Widgets per Page

In my previous blog post, I walked you through some scenarios of filtering content using URL parameters. We looked at using paging and filtering by taxon at the same time, while also keeping URLs different and SEO friendly. We learned that if we want to use named parameters, we should use the query string part of the URL. Today we’ll take a look at another scenario, which we’ve seen customers request. This new scenario involves putting multiple content widgets on the same page. Like before, we’ll use the News module as an example.

Independent filtering in widgets with URL key prefixes

For the purposes of our discussion, I’ve created a page, and put two news widgets on it, in different placeholders. The two widgets use a different template, one showing full content with the items, the other one only showing titles and dates.

With the default widget configuration, both of these widgets use the URL for filtering and paging. This means that once we switch to the second page in one of them, the other one will also switch, because the URL says so.

Also, if we open a single news item in one of the widgets, the other widget will show the same item. This is again because the URL is changed, and both widgets show what’s in the URL.

This behavior is not what most projects require. It is the default behavior, though, the reason being that widgets on the page cannot know which one of them should take action. The URL instructs to change the page, but does not tell which widget should do it. Same with displaying a single item. That’s why all of the widgets decide to take action.

We can change this if we want to (and in most cases we do). We can instruct all widgets to generate and interpret URLs with their own key. This is done by setting the UrlKeyPrefix property in Advanced mode of the widget designer.

In the above scenario, I will call the left-hand news list “main”, and the right-hand list “sidebar”. I will set the UrlKeyPrefix property in the two widgets respectively.

The result of this is that now the two widgets will behave independently. Clicking the second page in the main list will not affect the sidebar list.

Notice that the URL has changed to include the URL key prefix for the widget, whose page we changed. Because of this, the sidebar widget doesn’t do anything. However, see what happens if we decide to switch to the second page in the sidebar list.

After clicking the pager, the URL is correctly changed with the prefix for the sidebar list. The sidebar widget recognizes this and takes action by displaying the second page. The main list, however, switches back to the initial state, and the page we were previously viewing (number 2) is lost. This is the same problem that I explored in the previous blog post. If we want to filter by multiple parameters (in this case two different parameters for paging), we need to name those parameters, and we can only do this if using the query string. After we do this, we can page through both news lists, and both parameters are kept in the URL.

Now that we’ve switched to QueryString mode and have set URL keys for the two News widgets, they will work independently and anything done in one will not affect the other. By using the combination of those two properties – UrlEvaluationMode and UrlKeyPrefix - we can cover a large number of scenarios with URL filtering and multiple widgets, depending on how we want those widgets to interact. This gives you the flexibility to configure the default content widgets for your project needs. Needless to say, this works in all built-in content modules and not just News.

Advanced Master-Details with two master views

A common scenario that we’ve seen is a somewhat extended version of master-details on the same page. The defined behavior is this:

• Have a main list of items in the main section of the page
• Have a featured list of items in the sidebar section of the page
• Clicking a single item from the main list opens it in-place (in the main section)
• Clicking a single item from the sidebar list opens it in the main list

Implementing this in Sitefinity is easy, after we’ve covered how multiple widgets on the same page communicate. There’s just one thing we haven’t seen yet, and this is the display mode of each content widget. Each content widgets can work in one of three display modes at a time – Automatic, Master or Detail. Automatic mode is the default and we’ve been using it everywhere up to now. If we specifically set the mode to Master, the widget will always display a list of items. Details mode will make the widget always display a single item.

With our above requirements, we want the list of featured items to always be a list and never switch to detail mode. This is done by setting the ContentViewDisplayMode property to Master. The video below walks through all steps we need to implement the above scenario.

Click here to view the video

Conclusion

In this and the previous blog post, we’ve covered some scenarios of filtering through the URL and how different content widgets on the same page communicate. We’ve used several advanced properties of these widgets to control their behavior.

• UrlEvaluationMode
• UrlKeyPrefix
• ContentViewDisplayMode

By using a combination of the above, you can implement a number of schemes, depending on the requirements of your project. If we also add the ability to use content widgets on different pages, the possibilities are practically limitless. We’d like to hear how you use the content widgets, while developing sites on Sitefinity. Share your experience in the comments.