Razor Views and ViewComponents

For developers working with Optimizely CMS 12 in a Platform-as-a-Service (PaaS) environment, understanding how content templates are rendered is fundamental. CMS 12 leverages standard ASP.NET Core MVC and Razor to display content, giving you robust and flexible mechanisms for building dynamic web experiences. This article breaks down Razor Views, ViewComponents, and the key extension points in the rendering pipeline.

1. Models, Views, and Templates in Optimizely CMS 12

Optimizely CMS 12's rendering flow is rooted in the Model-View-Controller (MVC) pattern. This separation of concerns supports maintainable and scalable implementations:

• Model: Represents data and business logic, independent of the UI.
• View: Renders the model as HTML - typically a Razor .cshtml file.
• Controller: Handles routing and selects which view should render the current content.

Alternatively, Razor Pages offer a page-focused approach, pairing a Razor Page file (.cshtml) with a page model (.cshtml.cs) to separate presentation from page-specific logic. By convention, Optimizely MVC projects store renderers in the /Views folder.

2. Views: The Core of Content Display

Views - primarily .cshtml files - are the core display mechanism in CMS 12. They contain HTML markup plus Razor syntax to produce the final output sent to the client.

To keep rendering clean and reusable, developers use five key view constructs:

• Action-specific views: Views scoped to a single controller action for full-page content rendering.
• Partial views: Reusable UI snippets embedded inside other views - ideal for simple blocks with no logic.
• ViewComponents: Self-contained UI components combining logic and a dedicated Razor view.
• Layouts: Shared structural scaffolding for headers, footers, and navigation across pages.
• View models: Strongly-typed models built specifically for a view, decoupling the CMS content type from the rendering layer.

3. HTML Helpers for Dynamic Content

Views contain static HTML markup, but rendering Optimizely properties correctly - and making them editable by editors - depends on using the right helpers.

ASP.NET Core MVC and Optimizely CMS together provide a rich set of built-in helper methods. You can also create custom helpers to standardize rendering patterns across your site.

4. ViewComponents for Reusable UI Logic

ViewComponents are ideal when you need reusable UI with real logic - data fetching, composition rules, conditional rendering - that would make a partial view messy or hard to test.

They are especially well-suited for three scenarios:

• Reusable UI elements: Navigation, related content, promotional bands, shopping carts, and similar components that appear across many pages.
• Complex rendering logic: When the UI requires service calls, permission checks, or business rule evaluation before rendering.
• Separation of concerns: Keeps logic out of page controllers and partial views, preserving a clean MVC boundary.

A ViewComponent is a class inheriting from ViewComponent, exposing Invoke() or InvokeAsync() and returning a view result. It prepares data via injected services and hands it to a dedicated Razor view for rendering.

5. Controlling Rendering: Advanced Mechanisms

Optimizely provides mechanisms to control how templates are selected based on context - display options, delivery channels, and tags. Together, these enable adaptive rendering based on content type, display settings, and the channel serving the request.

Interactive Practice Ideas

Conclusion

Mastering Razor Views and ViewComponents is essential for building maintainable, performant, and editor-friendly Optimizely CMS 12 solutions. By understanding MVC, using helpers like Html.PropertyFor(), and applying Optimizely's template selection mechanisms, you can deliver consistent rendering across pages, blocks, channels, and contexts.