In our previous post - Filtering Sitefinity ContentView-based controls on the frontend we have demonstrated how you can easily inherit from a ContentView-based widget's default view and implement your additional business logic there. We also showed you how you can make this the default View Sitefinity will be using.
However we do realize that sometimes you might not want to apply your view globally, but rather be able to specify which widget would use your custom views, and which one will use the default.
With today's blog post we are going to quickly demonstrate to you how you can create custom widgets that behave just like the default ones, but can have your custom views set as default.
We can continue form the already existing sample of a custom masterView for the News widget, created for the Filtering Sitefinity ContentView-based controls on the frontend blog post. if you have not followed this post, or you're just interested in how you can extend the default master/Details view please follow that post first.
What we need to do now is to inherit from the default ContentView-based widget. In the case of the News module this is the Telerik.Sitefinity.Modules.News.Web.UI.NewsView class.
Each class inheriting form ContentView is able to dynamically resolve its current view (depending on whether it needs to show an item in list or details mode, for example). The collection of views is stored as a key value pair in the ContentView's ControlDefinition, and each view gets resolved by its name. Once we resolve the ViewType we load the corresponding control on the frontend.
This is a brief walkthrough of the beauty of the ControlDefinition implementation in Sitefinity and the flexibility it gives us.
Now if we get back to the current use case scenario, let's see how this ControlDefinition can help us achieve the desired functionality.
The only thing we need to do, once we've created our custom class that inherits from
NewsView is to override its CreateChildControls() method. The default ContentView class implementation resolves the ViewType and loads the View inside an override of CreateChildControls. As we've mentioned in the above paragraph, the ViewType and Viewname are stored as key-value pairs inside the ControlDefinition. So in order to tell our widget that it needs to load the custom ViewType instead of the default one we just need to say:
.ControlDefinition.Views.Where(v => v.ViewName ==
That's all, folks, believe it or not this one-line solution is the only thing we need to do to replace the default MasterView of our custom widget with the custom MasterView.
The only thing that's left now is to build the project, and register your new widget in Sitefinity. If you're using
Sitefinity Thunder you already know that this will take not more that 5-10 seconds.
A demonstrative video of the new widget's functionality, compared side by side with the default news widget can be found here.
A sample combining both the custom view from Filtering Sitefinity ContentView-based controls on the frontend and the custom NewsView from today's post can be found below: