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.
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.
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.
A common scenario that we’ve seen is a somewhat extended version of master-details on the same page. The defined behavior is this:
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
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.
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.
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.