Oak Component Engine

Case study at a glance

The problem, my role, and the result.

problem: Developers were repeatedly rebuilding the same HTML structures while swapping page-specific content. Global changes still required touching many individual instances.
stakes: Implementation time, consistency, and content-update turnaround all suffered, but the replacement still had to feel natural inside the established Oak CMS workflow.
My ownership: I designed and implemented the complete capability: authoring syntax, admin definition UI, rendering behavior, editor snippets, loops, and conditional template functionality.
outcome: The engine reduced new-site implementation time by approximately 50% and is now used by all Ninthroot developers as the primary method for new Oak CMS sites.

Architecture

The boundaries that made the work useful.

Content-facing syntax

Editors work with a concise XML-style component tag and structured data fields rather than duplicating full presentation markup.

Central definitions

Each component definition owns its HTML and styling contract, so sitewide updates can be made once instead of repeated across every page instance.

Template rendering

Loops, named data fields, and conditional chunks let one definition handle useful variations without forcing editors to understand the rendering logic.

Cross-site reuse

Definitions can be shared between sites, making established components portable while still allowing brand-specific presentation.

Approved public example

A concrete look at the implementation pattern.

Illustrative CMS component definition

html

This example shows the public component syntax and omits site-specific content.

<Accordion
  data-classes=""
  data-skip-auto-expand-tf=""
>
  <data-item>
    <data-header>
      ...
    </data-header>
    <data-body>
      ...
    </data-body>
  </data-item>
</Accordion>

Illustrative component template

html

The definition maps named fields, loops, and conditional chunks into shared markup.

<div id="accordion-{el_id}" class="wi-accordion {classes=}">
  {loop:item}
  <div class="accordion-item" id="heading-{el_id}-{loop_count}">
    <h3 class="h6 accordion-header">
      <button
        class="accordion-button {chunk:collapse_all}{chunk:collapsed}{/chunk:collapsed}{/chunk:collapse_all}"
        type="button"
        data-bs-toggle="collapse"
        data-bs-target="#collapse-{el_id}-{loop_count}"
        aria-expanded="false"
        aria-controls="collapse-{el_id}-{loop_count}"
      >
        {header}
      </button>
    </h3>
    <div
      id="collapse-{el_id}-{loop_count}"
      class="accordion-collapse collapse {chunk:show_none}{chunk:show}{/chunk:show}{/chunk:show_none}"
      aria-labelledby="heading-{el_id}-{loop_count}"
      data-bs-parent="#accordion-{el_id}"
    >
      <div class="accordion-body">
        {body}
      </div>
    </div>
  </div>
  {/loop:item}
</div>

Illustrative styling excerpt

scss

Presentation stays with the reusable definition while each site can apply its own variables and brand rules.

.wi-accordion {
  .accordion-item {
    border: none;
    background-color: transparent;
    border-bottom: 1px solid rgba(0, 0, 0, 0.20);

    .accordion-header {
      font-size: 1.125rem;
      font-family: var(--font-secondary);
      font-weight: 600;
    }
  }
}
// ...continues

Key decisions

What I chose and why.

01
Used a small CMS-native component language instead of adding React to a legacy rendering platform.
02
Kept content and presentation separate so non-technical teammates could change options and copy without editing the underlying structure.
03
Built conditional and loop behavior into the definition layer so the same component could cover real site variations.
04
Added editor snippets and a definition UI so adoption did not depend on developers memorizing syntax.

Outcome & evidence

What the repository and delivered work support.

01
Approximately 50% reduction in new-site implementation time.
02
Used as the primary implementation method for all new Oak CMS sites.
03
Adopted by all Ninthroot developers with minimal training.
04
Used across dozens of sites, typically with 10 to 50+ components per site.
05
Non-technical team members can update component content and options without editing the underlying structure.

Reflection

What I learned and what I would do next.

What I learned

The useful abstraction was not a bigger framework. It was a focused layer that matched the CMS, the team, and the recurring work closely enough to remove repetition.

What I would do next

I would keep strengthening validation and authoring feedback as the component catalog grows, while protecting the simple mental model that made the system easy to adopt.