Designing Views

In Optimizely CMS 13 (PaaS), the editorial experience has evolved significantly through the introduction of Visual Builder. For developers, this means the rendering layer must now be both preview-aware and cloud-synchronized. Whether you are building an in-process Razor head or a decoupled React frontend, your views must be capable of rendering real-time draft content delivered through Optimizely Graph.

This guide explains the technical requirements for ensuring your rendering layer remains compatible with the modern Graph-backed preview infrastructure used by CMS 13.

1. How Graph-backed Preview Works

In earlier CMS versions, previewing content was primarily a database operation. The CMS would load a draft version of a page from local SQL and render it through the local template engine. In CMS 13, however, the preview architecture follows a cloud-first orchestration model powered by Optimizely Graph.

1.1 The Technical Flow

1. Draft indexing: When editors modify content in Visual Builder, changes are synchronized to a secure draft namespace within Optimizely Graph.
2. The handshake: The CMS initiates a secure session with the rendering head configured via ExternalApplicationOptions.
3. Communication tokens: The CMS provides a signed, time-limited token through headers or query parameters.
4. Real-time retrieval: The rendering head uses this token to request unpublished content from Graph, allowing editors to preview changes without affecting the public index.

2. Modeling for Visual Builder Compatibility

To fully support Visual Builder previews, developers should align their models with the newer Experience and Element composition patterns.

• Experiences: Top-level layout containers designed to integrate with Visual Builder's drag-and-drop composition model.
• Elements: Atomic content units (similar to blocks) used by the builder to construct modular page layouts.

2.1 Metadata Exposure for Visual Builder

For views to work correctly within the Visual Builder iframe, they must expose metadata that allows the CMS interface to identify and highlight editable elements.

When using Razor, helpers such as @Html.PropertyFor() automatically inject the metadata required for editing overlays. In a headless React implementation, developers must request metadata fields such as Version and ContentLink through GraphQL queries and attach those identifiers to DOM elements so Visual Builder can bind its editing tools correctly.

3. Configuring the Secure Preview Handshake

A key requirement in PaaS implementations is securing the communication channel between the CMS and the rendering head. This is achieved by defining preview URLs and authentication tokens within the application's startup configuration.

4. Handling Render Settings Dynamically

Visual Builder introduces Render Settings, which allow editors to apply layout attributes such as spacing, background themes, or width constraints to sections. Templates must interpret these settings dynamically during rendering.

Rendering components should examine incoming view model metadata and translate those settings into CSS classes or layout behaviors to maintain design consistency across the site.

Conclusion

Designing views for CMS 13 requires a shift toward preview-aware rendering. By ensuring that templates can resolve signed preview tokens, retrieve draft content from Optimizely Graph namespaces, and dynamically interpret Visual Builder render settings, developers can deliver a seamless editorial experience. When the rendering head and CMS control plane operate in sync, editors gain real-time feedback while the platform maintains the high-performance delivery expected in modern PaaS environments.