Page Models

Page models describe the different page types that are available to your content managers when creating a new page. Every page in Redakt CMS is of a certain page model. Examples of page models are the home page, a content page, a news item, a blog post, etc. A page model describes the properties and sections of content that are available on a certain page. These content items can themselves be defined with a content model (see here).

You can create a page model simply by creating a new class. The class must implement the IPageModel interface. This interface does not contain any members itself, but it allows the system to recognize the class as a page model. It does not matter in which namespace or assembly the page model is located; the system will register all page models in your project on startup.

The main purpose of defining page models is configuration of the sections of the page and which type of content is allowed on them, and defining page hierarchy through allowing certain child page types and layouts. Below is an example of what a page model could look like.

This example contains several class and property attributes that define the behavior of a model. Below is a list of all Redakt built-in attributes that can be applies to page models.

[AllowChildren(typeof(ContentPage))]
[DefaultSection("Content")]
public class ContentPage: IPageModel
{
    // Default section 'Content'
    [Required]
    public string PageTitle { get; set; }

    // Default section 'Content'
    [Multiline]
    public string Summary { get; set; }

    // Explicit section 'Open Graph'
    [Section("Open Graph")]
    [DisplayName("Image")]
    [Shared]
    public ImageContent OpenGraphImage { get; set; }

    // Explicit section 'Open Graph'
    [Section("Open Graph")]
    [DisplayName("Image")]
    public string OpenGraphTitle { get; set; }

    // Explicit section 'Open Graph'
    [Section("Open Graph")]
    [DisplayName("Description")]
    [MultiLine]
    public string OpenGraphDescription { get; set; }

    // Section 'Modules' by convention
    public List<IContentModel> Modules { get; set; }

    // Section 'Footer' by convention
    public FooterContent Footer { get; set; }

    // Section 'SEO' by convention
    [DisplayName("SEO")]
    public SeoContent Seo { get; set; }

    [IgnoreMember]
    public string SomeProperty { get; set; }
}

Sections

Let's take a look at this example. ContentPage is a regular class that implements the IPageModel interface as required by the Redakt system. The class contains a number of properties. A property is considered part of the model if the following criteria apply. All other properties are ignored and do not play any role in the Redakt system.

  • The property is not decorated with an IgnoreMember attribute attribute.
  • The property has a setter (does not have to be public).
  • A valid property editor can be determined for the property type.

Properties are grouped in sections in the back office user interface. These are rendered as tabs on the page edit view. Which section a property appears in is determined by the following logic:

  • If the property is explicitly decorated with SectionAttribute, it will always appear in that section.
  • Otherwise, if the property type is nested content, it appears in its own section with the display name of the property. A property type is considered nested content when it is or implements IContentModel, or is an ICollection (interface or concrete class) thereof, and is not shared (decorated with SharedAttribute).
  • Otherwise, if a default section is specified on the page model with DefaultSectionAttribute, the property will appear in the default section.
  • Otherwise, the property will appear in a section named 'Content'.

Child Pages and Layouts

Page models also determine the hierarchy of the page structure. If not specified, any other page model may be used for child pages of a particular page. In most cases however, you will want to restrict which page types are allowed as child pages of a page model. So for example for a NewsListPage you may only want to allow NewsArcticlePage models as child pages, ensuring that a content manager will not accidentally create a ContactPage below the news list.

In order to do that, you decorate the class with a AllowChildren attribute. In the constructor, you pass one or more page models that may be used as child pages of pages with this model. In the example above, only ContentPage models itself are allowed as child pages of a page with a ContentPage model. You can add as many as you require.

If you omit the AllowChildren attribute, all page models are allowed as child pages. If you add the AllowChildren attribute without passing any models, no page model is allowed as child page, effectively enforcing leaf nodes in the page tree.

Besides the page model, you can also restrict the page layout that is allowed for the page. The page layout determines how a page is displayed on the website, whereas the page model determines the content that is available on the page. So for example a NewsPage model could be displayed as a full news page (layout), or as a news article summary, where both layouts use the same page model.

Inheritance

You can inherit a page model from another (base) page model. The derived page model will inherit all properties and sections from the base class, and add its own properties. The following model will have all the properties of the ContentPage model, and adds an ExtraContent section.

[AllowChildren(typeof(ContentPage), typeof(NewsPage))]
public class NewsPage: ContentPage
{
    public ExtraContent Extra { get; set; }
}

When setting allowed child models with the AllowChildren attribute, any derived models that may be used as child models have to be allowed explicitly. Therefore in the example above, the NewsPage model has to be allowed explicitly, even though the ContentPage is already included, which is a base class of the NewsPage model.

Attributes

Page models and sections can be decorated with a number of attributes that change the behavior of the page or section. All attributes are optional, and default configuration will be set by convention. See the attribute guides for detailed instructions.

Page attributes

The following attributes can be applied to a page model (class).

Property attributes

The following attributes can be applied to page model properties.