In the last post, we looked at creating reusable common collections of fields for Sitefinity widgets. We did this by leveraging a combination of Interfaces and MVC partials. If it wasn’t immediately clear why one would go to the effort of using this method to add a couple of fields to a widget, it's to create a scalable, reusable process. For the singular use we showed earlier, it might certainly seem like overkill for the required purposes. However, if we think ahead and consider the widgets we might have to build in the future, the widgets we don’t yet know the requirements of, the widgets we have yet to define, design and build for future projects. With this in mind, we find it a much better practice to standardise our coding and produce elements that standardise our output. While the short-term effort might seem like more than is required for such a simple use, the long-term benefits quickly speak for themselves. We can reuse these collections more readily and more quickly once the implementation is completed.

There are further knock-on benefits; we know these fields have been tested, so we can reuse them with confidence. We know the collections have been integrated in other widgets already so the likelihood of there being significant errors or problems in the integration is greatly diminished. We also know that the code used has been signed off on, standardising and improving our overall coding practices. This greatly improves the overall stability of our code and ensures it meets our own internal standards.

So, once we have this code written, what happens? Surely there’s not one-size-fits-all with this code? Clients have different requirements and expectations regarding how widgets function. Today, we’re going to look at how to use these practices to create and reuse the same widget in multiple ways.

To do this, we will use a common widget template naming convention (widgetname.template.cshtml) and some modifications to the widget controller.

Controller Changes

Add the following template name variables to your controller:

private string templateName = "DemoWidget";
public string TemplateName
{
    get
    {
        return this.templateName;
    }
    set
    {
        this.templateName = value;
    }
}

Change the index method to use the selected template for the view rather than the default "index".

Create re-useable Template Selector

In the designer view we need a dropdown selector to choose from available templates. This will be a list of ‘.cshtml’ files that fit the pattern. Like in the previous article, we make this re-usable for any widget by creating a template selector shared partial view (_TemplateSelector.cshtml in the /MVC/Views/Shared folder in the Github).

We define a model of type String so we can specify the naming convention to match (i.e. our widget prefix).

Add the partial view to our Designer View

Rename frontend view to match naming convention and test

We rename our template from “index.cshtml” to “DemoWidget.index.cshtml”

Once you build your solution and run the site, your widget designer should now look like this with one template choice:

Using a template naming convention to filter your widgets features available to content editors

Now we can get adaptive. Say, for example, the above widget would suit another section of the website, but the images don't need to be responsive. Our only requirement is that the widget supports a single image. Previously, we would have created a new widget for the single image, but the more efficient method is to create a new frontend view template within this current widget. Both options are fine, but for a content editor, it might be confusing, especially if there are multiple fields that aren’t used for all templates.

The solution is to use our template naming to filter features in the designer view.

For example, we might require the template name to include “.Responsive” to show the responsive image selector; otherwise, we just show one.

Create two templates, one using the name to indicate it is responsive

We create our two template variations: DemoWidget.Responsive.cshtml and DemoWidget.Single.cshtml:

With this change, in our designer view we want to only show one image selector when the single template is selected and show the two selectors when the responsive template is selected. We can use the AngularJS ‘ng-show’ Directive which allows us to evaluate an expression to decide whether to show an element or not. We create our two alternatives and apply the ng-show as follows:

(See Github)

We check whether the TemplateName property contains “Responsive” or not and display the appropriate designer markup.

Again, once you build and run your site and the widget designer should now look like this:

Widget Editor (Responsive):

Widget Display (Responsive):

Widget Editor (Single):

Widget Display (Single):

And that’s it! As you can see, using this practice creates a far better user experience for the site administrator. Rather than dropping in lots of different widgets of similar types to accommodate different requirements, the site admin drops in a single widget with multiple views based on the current requirements. This leads to less “widget clutter” (having many widgets to choose from) and makes the process simpler and more streamlined for the site admins. We’ve also optimised our code by reusing the required partials and intelligently adapting them to our requirements.

Conclusion

Reusing code is the holy grail of development. The more we can write scalable and reusable code, the fewer problems we run into as a whole and the faster our development process and cycle becomes. Sitefinity is a highly adaptable CMS and with its regular release cycle, leverages the best aspects of what .NET has to offer. While none of these processes is particularly difficult to understand or use, documentation explaining these practices seems limited. I hope this helps you to improve your widgets and optimise them to their full potential.

Arekibo is a certified Sitefinity partner based in Dublin, providing Sitefinity development, managed cloud hosting, upgrades and migration, and training and adoption services for enterprise clients across Ireland, the UK, and the USA.

If you or your company are looking for further advice or assistance in this domain, or would like to discuss your digital strategy, give us a call!