Table of Contents

Frontend template development

Build server-side rendered Razor (Swift) templates in Dynamicweb 10 with an AI assistant grounded in the documentation

Frontend development in Dynamicweb 10 means writing server-side rendered Razor templates that turn editor content into HTML. Each template inherits a strongly typed viewmodel — a PageViewModel, ParagraphViewModel, ProductViewModel, and so on — and reads content from it to produce markup. This is the model used by Swift, Dynamicweb's reference design.

The hard part for a developer new to the platform isn't Razor — it's knowing the API surface: which viewmodel you get, what properties hang off it, and the right helper to pull a value out of an item. That's exactly where the Documentation MCP Server earns its place in the loop. Connect it once, and your editor can answer "what's on ParagraphViewModel?" or "how do I read a button field?" from the real documentation while you type — instead of you guessing at class names or alt-tabbing to a browser.

This article shows what that workflow looks like for frontend work.

How a template is built

A Dynamicweb template is a .cshtml file that inherits a viewmodel. Here is a paragraph template that renders a heading block with two buttons:

@inherits Dynamicweb.Rendering.ViewModelTemplate<Dynamicweb.Frontend.ParagraphViewModel>
@using Dynamicweb.Frontend

<div>
    <div data-swift-text class="text-center mx-auto mb-0-last-child">
        @if (Model.Item.TryGetString("Title", out string title)) {
            @title
        }
        @if (Model.Item.TryGetString("Subtitle", out string subtitle)) {
            @subtitle
        }
        @if (Model.Item.TryGetString("Text", out string text)) {
            @text
        }
    </div>
    <div class="d-flex flex-wrap gap-2 align-items-center justify-content-center">
        @if (Model.Item.TryGetButton("FirstButton", out ButtonViewModel firstButton)) {
            <a href="@firstButton.Link.Url" class="btn btn-@firstButton.Style" data-dw-button="@firstButton.Style">@firstButton.Label</a>
        }
        @if (Model.Item.TryGetButton("SecondButton", out ButtonViewModel secondButton)) {
            <a href="@secondButton.Link.Url" class="btn btn-@secondButton.Style" data-dw-button="@secondButton.Style">@secondButton.Label</a>
        }
    </div>
</div>

A few things to notice, because they recur in every template you write:

  • @inherits ... ViewModelTemplate<T> sets the viewmodel type. Pick the wrong T and Model exposes the wrong API — so this single line is worth getting right
  • Model.Item is an ItemViewModel — the structured content the editor filled in. The TryGet* helpers (TryGetString, TryGetButton, TryGetInteger, TryGetLink, etc.) read a named field and tell you whether it was set, which keeps the template clean of null checks
  • Field names are strings ("Title", "FirstButton") that must match the field system names on the item type. Typos here fail silently — the field just renders empty

The friction is the same in all three bullets: you need to know the right type, the right helper, and the right field name. An assistant grounded in the docs removes most of that.

Where the MCP fits

With the Documentation MCP connected, your coding assistant can query the published documentation and API reference mid-task. Instead of producing plausible-looking Razor that references methods that don't exist, it checks the real ItemViewModel, ParagraphViewModel, and ButtonViewModel definitions first and writes against them.

The payoff for frontend work specifically:

  • The right viewmodel, every time. - Ask which @inherits line a product list paragraph needs, and you get the actual type instead of a guess
  • Real helper methods. - TryGetString vs GetRawValueString vs GetString behave differently, and the assistant can pull the signatures from the docs and pick the one that fits
  • Fewer silent-empty bugs. - When generated code reads a field, it can be checked against the documented field-access pattern rather than an invented one
  • Learn the platform while you build. - Every answer comes back with references to the source articles, so you pick up the model instead of just pasting output

Examples

These are written for a server-side Razor / Swift workflow. The pattern is always the same: tell the assistant to use the Dynamicweb documentation, then ask.

Scaffold a paragraph template

Using the Dynamicweb documentation, write a paragraph template that inherits ParagraphViewModel and renders a Title, a Text body, and a single call-to-action button. Use the TryGet* helpers and show the correct @inherits and @using lines.

Because the assistant resolves ParagraphViewModel, ItemViewModel, and ButtonViewModel from the docs first, the skeleton it produces uses the real helper signatures — close to the example above, not an approximation.

Find the right viewmodel and helper

I'm building a product detail template. Check the Dynamicweb docs — what should I inherit, and how do I read the product name, price, and a custom product field?

The assistant retrieves the ProductViewModel reference and tells you the @inherits line plus the documented way to reach product fields, instead of inventing property names.

Understand a method before you trust it

What's the difference between Model.Item.TryGetString and Model.Item.GetRawValueString? Check the documentation and tell me which to use for a rich-text field.

This is the kind of question that's slow to answer from a browser and fast from the MCP — and it stops you from reaching for the wrong helper.

Verify assistant-generated code

Here's a template my assistant wrote. Check each Model.Item call against the Dynamicweb docs and flag anything that isn't a real method.

Using the MCP as a fact-checker on generated Razor catches hallucinated methods before they reach a .cshtml file and fail silently in the frontend.

Patterns that work well

  • Lead with the docs. "Using the Dynamicweb documentation, …" nudges the assistant to query the MCP rather than answer from general knowledge.
  • Ask for the @inherits line explicitly when starting a new template — it's the decision everything else depends on.
  • Ask for the helper, not just the value. "How do I read field X" gives you the documented access pattern, which generalizes to the next field.
  • Fact-check before you trust. Run generated templates back through the MCP to confirm every viewmodel call is real.
Note

Companion articles on C# extension development and headless development with the Documentation MCP are coming as this section grows.

Improve this doc
To top