## Definitions

A _layout_ is a configuration of _containers_ and [component](🔗) instances into a hierarchy.

A _container_ is a placeholder in a layout for one or more component instances added and configured by site editors in the Experience manager.

Layouts define the basic structure or template for a generic page layout. These layouts define the tree structure of component instances that should be present in all pages using that layout. These layouts are linked with specific documents via [routes](🔗) to generate individual pages.

Example two column layout from the Reference SPA channel template.

Example two column layout from the Reference SPA channel template.

One layout can extend another. Typically, a site configuration will contain a generic base layout that defines static components and containers for, for example, a header, a footer, and a main content area. More specific layouts then extend this base layout and add for example a certain number of rows or columns in the main content area and a number of containers for the site editors to place managed component instances in using the Experience manager app.

There are three different layouts types: _abstract_, _page_, and _xpage_.

  • _abstract_ layouts are used to define generic layouts that are meant to be extended.

  • _page_ layouts are used to define layouts for [document-driven pages](🔗).

  • _xpage_ layouts are used to define layouts for [Experience pages](🔗).

Only abstract layouts can be extended.

## Example

Consider the following example:

A "base" abstract layout defines a "header", and "main" content area, and a "footer" using static components. The "header" and "footer" components have a container embedded so that site editors can place managed component instances in them.

A "content" page layout extends the "base" abstract layout, adds a container to the "main" component, and adds a "right" component with a container.

The resulting aggregated layout is as represented below in the right column. Site editors will be able to place managed component inside the "header", "main", "right", and "footer" components' embedded containers.

Layout definitionsAggregated layout
<li>base</li> <ul> <li>header (static component)</li> <ul><li>container</li></ul><li>main (static component)</li><li>footer (static component)</li> <ul><li>container</li></ul></ul> <li> content (extends "base")</li> <ul><li>main (static component)</li> <ul><li>container</ul></li> <li>right (static component)</li> <ul><li>container</li></ul></ul><li>content (aggregated)</li> <ul><li>header (static component)</li> <ul><li>container</li></ul> <li>main (static component)</li> <ul><li>**container**</li></ul> <li>**right**</li> <ul><li>**container**</li></ul> <li> footer (static component)</li> <ul><li>container</li></ul> </ul>

The example below shows the JSON representation of the "content" layout in the sample application:

Note that if you retrieve the JSON for the "base" layout (for example, using the Postman collection), you'll see it has a few more components than "base" in the simplified example above. The principle remains the same, however: "content" extends "base" by adding additional components and containers.

For an overview of all layout properties, see the [Layout schema](🔗) in the Site Management API reference documentation.

## Layout Operations

The Site Management API treats each page layout and all of its contents as a single entity. Thus, the API provides a coarse grained management approach and changes to nested containers and components can only happen by updating the entire layout. For updates, a GET request is usually executed first, to retrieve the whole hierarchy of a page layout (and also the latest X-Resource-Version header).

See [Channel Layout Operations](🔗) in the Site Management API reference documentation for a list of operations.

You can find examples of using the layout endpoints in the [Postman collection](🔗).