Concepts

Glossary

The core vocabulary of Kestros. These terms recur throughout the guide. Each definition links to the concepts it depends on, and to the pages that cover it in depth.

A Kestros site is assembled from small, reusable components whose look is supplied separately by a UI Framework. Most other terms hang off those two ideas.

Platform

Kestros#: An open-core content management system for building and running websites: the core is open source, with commercial modules available on top. It is built on Apache Sling, the JCR, and OSGi.
Apache Sling#: A web framework that uses a Java Content Repository to store and manage content, mapping each request URL to a content resource and selecting a script or servlet (a small server-side program) to render it. Kestros is built on Sling.
JCR / Content Repository#: The Java Content Repository (JCR): a specification for a uniform Java API to store and access content as a tree of nodes and properties. Kestros keeps everything here: pages, components, libraries, frameworks, and sites.
OSGi#: A dynamic module system for Java: applications are built from reusable modules called bundles, wired together at runtime. Kestros’ back-end services run as OSGi bundles. (An OSGi bundle is distinct from a Kestros Component below.)
HTL (HTML Template Language)#: HTL (HTML Template Language), formerly Sightly, is Apache Sling’s server-side template language for HTML, kept close to plain HTML. In Kestros it is used to write component views. See Writing HTL.
Maven#: Apache Maven is a build and project-management tool based on a project object model (POM). Kestros projects are generated from a Maven archetype and built and deployed with Maven.
Docker#: An open platform for building, shipping, and running applications in containers. A published Docker image runs a working Kestros CMS with a single command.

Primitives

Node#: A single item in the content tree, the basic unit of storage (Sling exposes it as a resource). Everything in Kestros (a page, a component, a library) is a node. Like a folder, a node can hold properties and contain child nodes.
Property#: A named value stored on a node, such as text, a number, or a list. The properties on a node are its settings. A setting name usually carries a namespace prefix (for example kes:datasource), while plain authored text does not. Each feature’s guide page lists the properties it uses.
Render#: To turn a component and its content into the HTML that a browser displays.
Namespaces (kes:, sling:, jcr:)#: The prefix on a name says who defines it: sling: is Apache Sling’s, kes: is Kestros’, and jcr: is the standard repository’s. So sling:resourceType, kes:datasource, and jcr:title come from three different layers.

Content

Site#: The pages of one website, managed together under a common root. Its pages inherit their UI Framework and theme down from that root.
Page#: A single web page you author and edit, created from a page template and filled with components. Its look comes from a UI Framework (through a theme) that the page sets or inherits from its parent.
Dynamic Page#: A single template page that serves many URLs. A kes:DynamicRoute maps a pattern like products/{sku} (relative to the site root) to the template; Kestros matches the request, hands the captured value to the page, and a datasource uses it to fetch that item’s content. So one template backs every product, instead of a page per item.
Page Template#: The starting point for a new page: it sets the page’s structure and defaults. Kestros ships a basic template you can use as-is or extend into your own. See Page Templates.

Components

Component Type#: The definition of a component: its title, group, dialog, Sling Model, and views. Developers build component types; each component on a page is an implementation of one. The definition lives in a definition resource.
Definition Resource#: The node that holds a component type’s definition, the one a developer edits. In source it is a .content.xml file of type kes:ComponentType. The Component Type is the concept; the definition resource is the concrete node.
Component#: An implementation of a component type, placed on a page. It is a content node whose sling:resourceType points at its component type. This is what content authors work with when building a page.
Component View#: The HTML that renders a component. A component type ships a base “common view”; a UI Library or UI Framework can then supply its own, so the same component can look different depending on the framework a page uses. See Component Views for how a view is chosen.
Dialogedit dialog#: The form an author fills in to configure a component, shown in the editing UI. This usually means the edit dialog; other action dialogs (create, delete, and so on) are provided generically and can be overridden. See Dialogs & Fields.
Sling Model#: A Java class that gives a component (or a datasource) its server-side logic, turning stored content into typed values a view can use.
Core Component#: A component that ships with Kestros, ready to use out of the box. You can browse the full set from the component-management area of a running instance; see Components for the built-in list.
Custom Component#: A component you build for your own project, under apps/{project}/components/. A custom component doesn’t need a datasource; add one only if it has to show dynamically supplied content. See Custom Components.
Datasource#: A source that supplies a component’s content instead of the author entering it by hand. For example, a Card List can pull its cards from one. A datasource is a Sling Model, and an author selects it by name with the kes:datasource property. A component view lets a component swap its markup; a datasource lets it swap its data. See Datasources.

Styling & frontend

UI Librarynode type kes:VendorLibrary#: A reusable package of CSS, JavaScript, and component views, a building block. A UI Framework assembles one or more of them into the styling a site uses. In the repository its node type is kes:VendorLibrary and a framework references its libraries through kes:vendorLibraries. The docs are standardizing on the term “UI Library”, while the underlying node and property names stay as they are. See UI Libraries.
UI Framework#: The styling layer for a site: it decides which CSS and JavaScript load and which HTML renders for each component. It inherits views and styles from one or more UI Libraries and can override or combine them. Pages connect to it through a theme. See UI Frameworks & Themes.
Theme#: What a page binds to for its look, one of a UI Framework’s themes. Every framework has a default; extra themes let the same components appear as different brands. A theme can add its own CSS and JavaScript on top of the framework’s shared styles.
Layout#: A selectable HTML variant within a component view: a kes:Layout node holding that arrangement’s markup, chosen by name from a page’s content. The view is the component’s whole rendering; a layout is one arrangement it offers. Where a variation adds a CSS class to the same HTML, a layout swaps the HTML itself. See Layouts.
Variation#: A named CSS class an author can switch on for a component from its design options in the editor. Variations are the intended way to offer style choices; any class an author applies by name should be registered as a variation. See Variations.

Packaging & delivery

FileVaultApache Jackrabbit FileVault#: Apache Jackrabbit FileVault: the tool and file format for serializing JCR content to and from the filesystem as XML. Kestros content is authored as FileVault content, the .content.xml files.
docviewdocument view#: The FileVault “document view” XML serialization of JCR nodes, the .content.xml format. Because a node’s type and properties are carried in this XML, docview nodes must be delivered as a content package rather than as raw files.
Content Package#: A zip of JCR content in FileVault format, installed through the repository’s package manager. In a Kestros build the installPackage / installContent Maven profiles install these.
Sling-Initial-Content#: An OSGi bundle manifest header that loads content bundled inside a jar into the JCR when the bundle installs. Contrast with a content package: docview .content.xml loaded through Sling-Initial-Content lands as sling:Folder nodes and loses its node type, so ship docview content as a content package instead.

Missing a term? This glossary tracks the guide’s vocabulary as it fills out. New terms get added as their pages are written.