Content in Optimizely Content Management System (CMS) consists of pages, blocks, media files, and folders. It can also be catalog content in Optimizely Customized Commerce.
## Model, views and templates
CMS has built-in template support for ASP.NET Core MVC and Razor pages which are covered in this section. CMS can, however, also be used by other rendering techniques such as client-side rendering frameworks.
MVC stands for **Model-View-Controller** meaning:
The **Model** handles the business logic and is independent of views and controllers.
The **View** just displays data such as a web page, and knows only of the Model.
The **Controller** handles the user interaction and input logic, and has knowledge of both Model and View. As the controller is not dependent on a specific view, it can be reused and tested independently.
The rendering is based on views and templates. In MVC, a template corresponds to a controller and a view, where the controller selects the view to display. The view contains the actual HTML template with embedded code, generating content sent to the client.
By default, MVC applications rely heavily on conventions. For example, when resolving view templates, the system will look for a view template file in a folder with a specific path and name.
A typical Optimizely MVC project often uses the following folder structure to help you organize your code:
_/App\_Data_ with the content database (in case you choose to attach to an mdf file), and the default log file.
_/Business_ for business logic and helper libraries added during development.
_/Controllers_ for controller classes handling user input and responses.
_/Models_ for content classes representing and manipulating data.
_/Static_ for design and layout files such as scripts, images, and style sheets.
_/Views_ for renderers.
See [Create a starter project](🔗) for more details.
## Content model
The content system in CMS supports **strongly typed models**, and is based on content types in the CMS **content model**. Content in CMS can be almost anything, as long as it is a class that implements the `
IContent` interface. This also provides a set of important basic properties such as the content display name, as well as references and unique identifiers for a content item. See [Content](🔗).
Content instances, content types and content templates for example, are linked together in the following way:
A content type defines a set of properties, for example, page name and publish date, where editors enter content.
A content is an instance of the .NET class defining the content type. When a content item is edited, values are assigned to the properties, and stored in the database.
The controller and view fetches the stored property values and renders the output.
A template can be associated with the content type, to render the output in a certain context
### Page types
Episerver has a wide range of base classes. Page types are usually defined in code as classes based on a model inheriting from `
EPiServer.Core.PageData`. A `
PageData` object is the programmatic representation of a page, containing the properties defined in your .NET class. The value of `
currentPage` is automatically set to the `
PageData` object that is requested by the client.
During website initialization, the synchronization engine in CMS scans and validates available content types and properties created in code, or from the CMS admin view. The bin folder is scanned for .NET classes inheriting `
PageData `. For each of the classes found, a page type is created. For all public properties on the class, a corresponding property on the page type is created.
The synchronization merges the settings stored in the database (from admin view) with settings defined in code. If the settings conflict, the database setting values take precedence. This means that any settings saved through the admin view will override settings defined in code. See [Synchronization](🔗).
Properties store and present data for content in a page type. Properties are added in code, and can be accessed using inline expressions, in markup or in code-behind. The property data type dictates the kind of values that can be entered or rendered. Episerver comes with a set of built-in property types, and you can also define your own. See [Properties](🔗).
Pages are created by editors, and based on a specific page type. Pages build up the page tree structure in edit view. Information (both content and meta data) that is saved on a page instance, is stored in the CMS database.
### Rendering and templates
You can define several different templates (such as Controllers/Views, Razor Pages, view components or partial views) for displaying content in certain context, for example inside another page, or through different channels and devices such as a mobile phone. There are several ways to control the rendering. You can work with `
TemplateResolver`, and `
DisplayChannel`, to ensure that the correct rendering is applied depending on display context. See [Rendering](🔗).
Views are _.cshtml_ files stored in the _Views_ folder. If your view only needs the page object, you can simply pass the `
currentPage` into the view. Use action-specific views, partial views/controllers, and layouts to reduce code repetition. You can also create view models to make your views more flexible. See [View models and partial views](🔗).
## HTML Helpers
A view contains the HTML for specifying the markup. HTML Helpers render property values based on their property type. Properties can be rendered as markup using the `
Html.PropertyFor()` method. Using this, properties automatically become editable in edit view. Both ASP.NET MVC Core and Optimizely CMS comes with a predefined set of `
Html.Helper` methods to specify the HTML needed for the view. You can also create your own HTML Helpers.