This post is Part 4 of a 5-part series: Architecting Widgets in Sitecore.
You can navigate the other posts in this series by clicking on the links below. You can always refer back to Part 1: Introduction, key questions and terminology for any clarification around Sitecore terminology used in this series.
- Part 1: Introduction, key questions and terminology
- Part 2: Clean and Simple: Using a rich text area
- Part 3: Usability Plus: Using the Page Designer
- Part 4: Mix n’ Match: Building a widget library
- Part 5: Ultimate Flexibility: Complementing the Page Designer with a data source
In this post, we will be looking at how to build a widget library from which multiple widgets can be selected for a web page.
Mix n’ Match: Building a widget library
Implementation: Medium
Content Authoring Process: Easy
It’s wise to consider this scenario if you want content authors to be able to edit parts of a widget and reuse it over multiple pages. For example, the widget may consist of an ad box where content authors can add specific text and images. In this case, you will need a data template to store these editable data fields. The template-based widgets can then be stored in an intuitive widget library that resides somewhere in the content tree. The parent page, where you will be placing them, will have a multi-list field, pointing to your widget library. This allows you to select from multiple widgets.
The tricky part of this approach comes with presenting the widget. It’s all well and good to have a text field and an image field—but how will they be rendered or drawn? In Sitecore, there are three options for rendering these types of widgets.
Option 1 – Widget is drawn by the parent layout
Since a data template cannot be natively assigned a default sublayout or rendering to draw itself, in this option, the parent page becomes responsible for grabbing information from the widget data fields and drawing the widget. In order for this to work properly, the parent page layout is coded to display the widget in that place – it is not something that can change once that code is written. So the parent layout must know what widget and corresponding data fields to expect. This option works well if your widget is specialized and will only appear in a very specific place (for example, a profile spotlight appearing on a homepage).
This scenario is not ideal for a more general application, as it would not be efficient to create such extensive dependencies between parent and child templates throughout the site. They should remain independent whenever possible for better flexibility and to minimize cascading change effects.
Option 2 – Widget is purely rich text
If your widget can be drawn entirely with one rich-text field, it won’t need layout help from the parent page. In this case, widgets would still be stored in a library and selected from a multi-list.
Option 3 – Widget is rendered via user control
For a truly modular solution, the path to the widget’s sublayout or rendering can be stored as if it were another data field. During presentation, a User Control in the parent page reads the path and uses the assigned sublayout to present the widget.
In this post, we’ve looked at ways to build a widget library from which multiple widgets can be selected for a web page. Stay tuned for Part 5: Ultimate Flexibility: Complementing the Page Designer with a data source where we’ll explore how to marry the Page Designer with a custom data source for ultimate flexibility. Part 5 will be published May 11.