Widget fundamentals
Overview
The following article describes the different parts that constitute an ASP.NET Core widget. It also specifies where you should place them and how should you name them.
ViewComponent (required)
Location
/ViewComponents/SitefinityDataViewComponent.cs
Naming convention
The name of the class must have the ViewComponent suffix.
Description
The ViewComponent class must comply with the following:
- The class must be public.
- The class must be marked with the
[SitefinityWidget] attribute.
This way, the widget is loaded and displayed during the page editing, inside the Sitefinity CMS widget selector.
- The class must contain a public
InvokeAsync method which receives as argument IViewComponentContext<SitefinityDataEntity>.
For more information, see Microsoft documentation » View components in ASP.NET Core.
Following is an example of a ViewComponent class:
View (required)
Location
/Views/Shared/Components/SitefinityData/Default.cshtml
Naming convention
The naming of the folders where you place the Default.cshtml is strict.
SitefinityData folder is the name of your widget.
RECOMMENDATION: We recommend naming the view Default.cshtml
Description
In this folder, in addition to the Default.cshtml, you can place all views available for a particular ViewComponent.
Following is an example of a View file:
Entity (optional)
Location
/Models/SitefinityData/SitefinityDataEntity.cs
Naming convention
The name of the class must have the Entity suffix.
Description
The Entity class represents the data that is persisted in the database. This separates the logic for persisting the values of the properties, kept in the Entity class, from the business logic for the view components, kept in the Model class
The Entity class presents only plain public properties with get or set. This is visualized in Sitefinity CMS backend, through the widget property editors. The widget editor autogenerates a separate field for each property of the entity.
You can use attributes and data annotations to configure the look of the fields or their visibility, to group them in sections and categories, to set their default values, to validate them, etc.
For more information, see Autogenerated widget property editors for ASP.NET Core.
Following is an example of an Entity class:
Model (optional)
Location
/Models/SitefinityData/SitefinityDataModel.cs and
/Models/SitefinityData/ISitefinityDataModel.cs
Naming convention
The name of the class must have the Model suffix.
Description
This classes contains the business logic of the widget. They receive the data from the entity and process it to generate a ViewModel with the data needed by the View.
RECOMMENDATION: Although none of these classes are required, we recommend you add all logic for the widget in them, including the requests to Sitefinity CMS services and to third-party providers.
Sitefinity CMS built-in widgets, expose an interface for the model and take advantage of the built-in ASP.NET Core dependency injection mechanism to provide capability for replacing and extending the default logic.
Following is an example of a Model class:
Following is an example of the model interface class:
ViewModel (optional)
Location
/Models/WidgetName/WidgetViewModel.cs
Naming convention
The name of the class must have the ViewModel suffix.
Description
This class is intended to contain Plain old CLR object (POCO) for providing data to the widget view. You can have more than one ViewModel class for a single widget, depending on the specifics of your different views.
RECOMMENDATION: We recommend using a ViewModel class to separate the logic of the view from the business logic.
Following is an example of a ViewModel class: