All widgets have designers where you configure widget properties. By default, widgets have two designer modes – simple and advanced. Simple mode is the simpler way to configure a widget. In the advanced mode, you configure individual properties of the widget.
You can add custom views to the widget designer by adding new template files and then adding the logic, or content, in the template files. Finally, you make the new view the default one.
To create a designer view template file:
In the ~/Mvc/Views/<WidgetName> folder, create a new template file, following the naming convention. For details, see Feather: Naming conventions.
For example, if you are creating a new view for the Content Block widget designer:
Next, you add content to the template file. For example, you want to add simple text input in the new view of the designer and to allow the user to change the content of the Content Block through this new input. To do this, paste the following code line in the template file:
<input ng-model="properties.Content.PropertyValue" type="text" />
As a result, you create a binding to a widget property of the Content Block widget named Content.
Once you run your project and open the widget designer, a new view with a text field appears. When you type in a value and save it, this value is displayed inside the Content Block widget.
By default, the new designer view you created is not the default one you see when you open the designer. To change that, you need to create a ~/Mvc/Views/[WidgetName]/DesignerView.[ViewName].json file. This file is used both for specifying the priority of your designer view and the custom component and script dependencies it has.
For details on script dependencies, see Feather: Extend designers with client logic.
To make your designer view the default one, you set its priority to 1 (the highest priority). Your file should look similar to this:
The designer view configuration file specifies the view’s dependencies and configures whether the view is visible in the designer or through the More actions menu of the widget. The file uses JSON syntax. The file lists parameters and values that define the properties of the view.
RECOMMENDATION: We recommend that you have at least one designer view configured, even though none of the parameters are required.
You can leverage the reusable client components to implement your custom widget designer views.
IMPORTANT: Make sure you add the components to the array of components of the JSON file, otherwise the view will not load.
In case some components, for example, input fields, require sanitization, you need to add the ngSanitize selector to the array of dependencies of the AngularJs controller.
Following is an example of a widget designer configuration file for a view named Simple. The file is named DesignerView.Simple.json after the naming conventions.
In the configuration file above:
You need to make sure the properties of the widget’s MVC controller CustomWidgetController.cs match the ones of the widget designer’s AngularJs controller CustomWidgetController.js. You do this by two-way binding these properties using the $watch functions. $watch functions are triggered when the value of the watched variable is changed. You usually use the $watch functions to intercept the change of a property, for example, when modifying the property value and before setting this value or before executing logic that depends on the new value.
If you are persisting a string in the MVC controller that represents a collection, for example, a collection of IDs, you use the $watch function in combination with the JSON.parse function:
To do the reverse - transform the collection back to a string representation to persist in the MVC controller, use a $watch function in combination with the JSON.stringify function:
You can enable the loading indicator during widget designer initialization to check whether there are any discrepancies in property bindings. You can thus get information about any errors. To do this, you use the $scope.feedback.showLoadingIndicator property.
Additionally, you can enable the display of error messages during widget designer initialization to provide you with information about property binding errors. You do this by using the $scope.feedback.errorMessage = data.Detail; expression. The data.Detail value contains the binding error information but you can also set other values to the $scope.feedback.errorMessage property in case custom initialization logic fails.
The following example demonstrates how to enable both options:
Back To Top
To submit feedback, please update your cookie settings and allow the usage of Functional cookies.
Your feedback about this content is important
Copyright © 2021 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, Ipswitch, 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.
Powered by Progress Sitefinity