Docs Developer Site
Developer Docs Cms Stable Pages Parts

Parts and Layouts

Contents

Parts and layouts are the building blocks editors place inside regions to compose pages.

Parts

Parts are leaf components in the page structure — they do not contain regions. Parts are typically used in combination with forms, and have a vast range of application areas.

Usage

Place a descriptor in your project: src/main/resources/site/parts/<part-name>/<part-name>.yaml.

Each part may declare a form using the schema system. The form data will be stored together with each component instance.

Example part descriptor
kind: "Part"
title: "Content List"
form: []

Custom icon

Parts support custom icons that replace the standard part icon in Content Studio. Place an icon (PNG or SVG) in the part folder with the same name as the descriptor.

For example, if the part is called mypart, the icon file should be called either mypart.svg or mypart.png.

Below are examples of what custom icons may look like in Content Studio.

Custom icon as seen in the part selector
Custom icons in the page components tree

Layouts

Layouts are essentially parts that support regions regions. This allows editors to create nested structures of components within the page. Layouts are commonly used to style groups of components in a specific way, or for columnar presentation of parts.

Usage

Place a descriptor in your project: src/main/resources/site/layouts/<layout-name>/<layout-name>.yaml.

Similar to page descriptors, layouts support both schema forms and regions.

Sample layout with three regions
kind: "Layout"
title: "3 regions"
form: []
regions:
  - name: "left"
  - name: "main"
  - name: "right"

Here is what an empty layout with three regions might look like in Content Studio’s visual page editor:

Layout selected in the page editor

Querying via GraphQL

Guillotine generates a GraphQL type for every part and layout config, following the naming convention <appname>_<partname>_PartConfig / <appname>_<layoutname>_LayoutConfig (with dots and dashes replaced by underscores). Use an inline fragment on that type to access typed config fields, or fall back to configAsJson when the front-end does not need typed access.

Typed part config

{
  guillotine {
    get(key: "/site/articles/hello") {
      components {
        ... on PartComponent {
          descriptor
          config {
            ... on com_enonic_app_superhero_featured_PartConfig {
              heading
              postCount
            }
          }
        }
      }
    }
  }
}
Response
{
  "data": {
    "guillotine": {
      "get": {
        "components": [
          {
            "descriptor": "com.enonic.app.superhero:featured",
            "config": {
              "heading": "Featured posts",
              "postCount": 5
            }
          }
        ]
      }
    }
  }
}

Untyped part config

Use configAsJson when you need to handle arbitrary parts generically — for example, a front-end that renders any registered part without knowing the schema at build time:

{
  guillotine {
    get(key: "/site/articles/hello") {
      page {
        regions {
          components {
            ... on PartComponent {
              descriptor
              configAsJson
            }
          }
        }
      }
    }
  }
}

Layouts follow the same pattern with LayoutComponent and <appname>_<layoutname>_LayoutConfig.

Contents

Contents