Flexibility Through Structure: How Sulu Separates Concerns
“Here is my new web app. I have put all my genius into it! And the design is really clever. The SQL statements don’t just return the data, they return the data formatted as HTML, ready to show in the browser. The business logic is baked into the frontend, using my proprietary Javascript framework, right where the input forms and result pages are. Everything in one place! Oh, wait — I did move some logic to the backend. The HTTP server component manages a cron job that checks for updates of the build toolchain. If a new version comes in, the cron job runs a stored procedure in the database that recompiles the app (from the sources I store in the database, along with all config) and restarts it automatically!”
Absurd? Definitely. The second name of such an app would be “Maintenance Nightmare on Web Street.”
Separation of concerns is a fundamental design principle in software development about separating a computer program into distinct sections. Separation of concerns (SoC) is crucial for well-designed applications because it makes software easier to use and maintain.
Sulu CMS separates concerns in multiple ways: it separates content structure from visual appearance; and decouples the frontend from the backend. Where other CMSs mingle content and presentation, Sulu achieves flexibility and clarity by keeping strict boundaries.
Despite the benefits of SoC, overlapping concerns are all too common, especially when it comes to content management systems (CMSs). In CMS development, the concept of content structure is often tightly intermingled with the concept of display because it's tempting to create everything in one place. For instance, a website theme developer might decide to bake all the site’s functionality into the theme. This feels like a convenient solution, especially for the client who gets everything delivered in one package.
The drawbacks quickly become evident when it is time to upgrade. On the next theme redesign, all the custom functionality needs to be ported to the new design. Content managers are compelled to upskill in frontend web development, and frontend developers are suddenly tasked with content management work.
When a CMS follows the principle of SoC, it’s designed so that every aspect — structure, appearance, functionality — has well-defined boundaries. This careful design creates an architecture and modularity that feels natural to the user. Sulu CMS is one of these applications. Read on to learn more about how a Sulu developer, theme designer, and content manager can focus on their own specific concern and ignore the rest.
⸻
We’re here to help you get it right
Do you need help planning your project? Get in touch, and we can fast-track you to success with our workshops as well as consulting and coding services.
⸻
Concerns in a CMS
What are “concerns” in the context of content management systems? For a CMS, the main concerns are content and its presentation. Content encapsulates data of all kinds: text, images, video, and metadata. Data is formed into a structure to display on the frontend, for example, landing pages, blog articles, product catalogs, wikis, and so on.
Structure and presentation often get intermingled, but there is a fine line between the two. The structure of a web page, for example, can have different appearances: desktop layouts typically differ from mobile device layouts. Tabular data can be rendered as a list, as a matrix of cards, or as a carousel widget.
Another important concern is about location: where do things happen in the system? A backend that renders the HTML, a frontend that implements crucial functionality — it’s not uncommon to see such a mixing of concerns in CMSs. To a certain extent, this is okay if the CMS design follows a “backend-first” or “frontend-first” philosophy. Static site generators are in the backend-first camp; they generate static HTML pages that the web server delivers verbatim to the browser. Rich client applications (RCAs), on the other hand, implement business logic in the browser, using the backend merely as a data store. Both approaches work well within the use cases they were designed for. A universal approach, however, strives to keep a clear distinction between frontend and backend.
Separating content structure from appearance in Sulu
Sulu follows a universal approach by defining a clear interface between the frontend and backend. Here’s how it works: The backend generates a page using the structure definition and content. The result is a data structure that the backend passes to the frontend. The frontend then takes this structure and applies layout and styling to it.
This approach offers great flexibility. The backend is entirely agnostic of the frontend — it doesn’t matter whether the frontend consists of Twig templates or a full React application. Similarly, the frontend only needs to understand the format of the data structure it receives and does not require any additional knowledge about the backend.
Page structure is an XML document
Structuring a page in Sulu happens in a descriptive way. An XML document captures the individual elements of a page without dictating how they should be displayed. The scope of this XML document is purely about defining a hierarchy of content building blocks. The central piece of this hierarchy is the <property> type. Properties represent predefined content types, such as text, dates, colors, email addresses, or custom content blocks.
A simple page structure definition looks like this (taken from the documentation):
<!-- config/templates/pages/event.xml →
<?xml version="1.0" ?>
<template xmlns="http://schemas.sulu.io/template/template" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.sulu.io/template/template http://schemas.sulu.io/template/template-1.0.xsd">
<!-- ... -->
<properties>
<!-- ... -->
<property name="startDate" type="date">
<meta>
<title lang="en">Start Date</title>
</meta>
</property>
<!-- ... -->
</properties>
</template>
This document defines a property of type date, and the only attributes are related to content: a title string, and the language used. It is up to the rendering template to specify how this date property is rendered.
Page layout is a Twig template or a React application
To render a page for the browser, Sulu uses the Twig templating engine. A Twig template combines HTML with placeholders to combine data with page layout.
The following placeholder refers to the date property defined in the page structure above:
{{ content.date }}
The Twig template has the full freedom of placing and styling the properties. Just as XML document does not take care of rendering, the Twig template does not need to be aware of the page structure. The date property is just a piece of data coming from the backend. And so the document structure and the visual appearance can be defined independently of each other, even by different people.
Separation by layer
The strict separation of concerns does not stop here. Being a first-class citizen in the Symfony ecosystem, Sulu exposes all the etiquette of a Symfony application. More specifically, Sulu is divided into separate layers: a data layer, a framework layer, and an application layer.
The data layer: PHPCR and Doctrine
CMSs are all about content, and content is data. With two established data persistence layers, PHPCR (together with the Sulu Document Manager) and Doctrine ORM, Sulu abstracts database technology away and decouples relational data handling from data structures used in the application.
The framework layer: Symfony and CMF
Sulu builds upon the well-known Symfony framework. Symfony itself leans heavily on SoC principles, which is specifically apparent in its bundle system. Moreover, Sulu’s chain router, an element from the Symfony Content Management Framework (CMF), separates static and dynamic routing so that each part can be maintained separately.
The Sulu layer: a modular application
On top of all this, the Sulu application builds another layer of modularized functionality. Whether portals, webspaces, search, or modules (such as contacts, assets, settings, or custom modules), everything has a clear place in Sulu — with well-defined responsibilities.
Wrapping up: Sulu perfects the art of SoC
Separating concerns has a lot of benefits. Changes to one component do not necessarily affect other components. Content experts, UI designers, and frontend developers can focus on their respective areas of expertise and remain experts rather than attempting to multitask as a “jack of all trades.”
Yet, separating concerns is not easy to achieve. Meticulous systems design and thorough implementation are the cornerstones of creating a CMS that separates the different areas of concern as rigorously as Sulu does.
For the users of such a system — the content managers, frontend developers, administrators, and authors — this design clearly pays off. If you are not a Sulu user yet, try it for yourself. Or simply contact us for a demo! We’re happy to show you Sulu’s outstanding capabilities.
