Concepts

Architecture & Concepts

Kestros is built around a few deliberate design goals. The most important one shapes nearly every concept in this guide: a component is decoupled from both its markup and its data, so the interface and the content evolve independently.

New to Apache Sling, the JCR, OSGi, or HTL? You do not need to know them going in. This page explains how they fit together, and the Glossary defines every term it uses.

The stack Kestros is built on

Kestros sits on four building blocks. Each one plays a distinct role. Understanding them in order is the quickest way to make sense of everything else in this guide.

JCR (Java Content Repository). The JCR is where content is stored. It holds everything as a tree of nodes, and each node carries named properties (its values and settings). Kestros keeps its sites, pages, components, and configuration in the JCR as nodes, so all of it is just content in one tree.

Apache Sling. Sling turns a web request into a response. It maps the request URL to a node in the JCR (Sling calls that node a resource) and then picks a script to render it. Because the content lives in the repository and the script lives separately, the same content can be rendered by different scripts: this is the split between content and rendering that the rest of the guide relies on.

OSGi. The Java back end is not one big application: it is a set of modular pieces called bundles that plug into a running system. Kestros’ back-end services and Sling Models ship as OSGi bundles, so features can be added, updated, or swapped while the server keeps running.

HTL (HTML Template Language). HTL is the template language Sling uses to turn a resource into HTML. It stays close to plain HTML, with a few attributes that pull in values from the resource. In Kestros the markup for a component, a component view, is written as an HTL file. See Writing HTL.

The Kestros component model on top. A page is a tree of component nodes. Each component node points at a component type through its sling:resourceType property. The component type supplies the markup (an HTL view, chosen for the UI Framework the page uses) and, optionally, a Sling Model for its server-side logic. Because the view is chosen per UI Framework, the same page content renders differently just by swapping the framework.

The content tree

Everything in Kestros lives in one place: the JCR, as a single tree of nodes. Code, content, and configuration are all nodes in that tree; they just sit under different top-level paths.

A few top-level paths carry most of what you work with:

/content holds site content, the pages you author. Kestros keeps sites under /content/sites.
/apps and /libs hold code and component types. /apps is your project’s; /libs is what Kestros ships.
/etc holds UI Frameworks and UI Libraries, under /etc/ui-frameworks and /etc/vendor-libraries.

A site is a kes:Site node. Its pages are kes:Page nodes beneath it, and each page’s jcr:content node holds the component nodes that make up the page. So a whole site, its pages, and their content are just one branch of the tree.

Request resolution

When a request comes in, Kestros turns the URL into rendered HTML in a fixed sequence. Apache Sling first maps the request URL to a resource: the JCR node at that path.

That resource carries a sling:resourceType property pointing at a component type. Kestros resolves that type by looking under /apps first and then falling back to the mirrored path under /libs, so a project can override a shipped type just by placing its own at the matching /apps path.

From the component type, Kestros picks the component view: the HTL template chosen for the UI Framework the page is using. That template renders the resource to HTML. The short version: URL to resource, resource to sling:resourceType, resourceType to component type, component type to the HTL view for the active UI Framework, view to HTML.

Inheritance

Kestros leans on two inheritance mechanisms so you set things once and let them flow down.

Theme inheritance down the content tree. A kes:theme path set on a page or site (on its jcr:content) is inherited by every page below it. When a page is rendered, Kestros walks up the tree and uses the kes:theme from the closest ancestor that has one set, so you can point a whole site at a theme at its root and override it on individual pages underneath.

Component types extending other component types. A component type can set sling:resourceSuperType to point at another component type and inherit its views, dialog, and logic, then override only the parts it needs. Most Kestros component types extend a shared base this way, for example kestros/commons/components/kestros-parent.

Design goals

Swap the UI, keep the site. Because core components give every site a shared vocabulary, and a component’s markup is supplied by the UI Framework in use rather than stored with the content, a brand-new UI Framework renders any existing site built on core components with no content changes. You can restyle or re-skin an entire site by switching to a new framework, and you can swap the datasource behind a component without touching its UI.

Content outlives the UI. Authored content is stored on its own, independent of any UI, so it survives framework and theme swaps. A page references a theme by path and the theme supplies the look; the page itself is never tied to one appearance.

See the Glossary for the vocabulary these concepts rely on.