Asset model

WebCmsModule provides a basic model for mapping assets and types. Example assets provided by default are WebCmsArticle and WebCmsPage. Related types would be WebCmsArticleType and WebCmsPageType.

1. WebCmsObject

Both types and assets are implementations of WebCmsObject. A WebCmsObject can be any object, as long as it has a unique objectId. The objectId is a String value, can be manually assigned but should never change once set. It should also be unique within a single data store.

The unique objectId is used for importing/exporting and synchronizing data.

2. WebCmsAsset

The base class for an asset is WebCmsAsset. Default implementations are WebCmsPage, WebCmsArticle and WebCmsPublication.

By default an asset has a concept of being published or not.

The repository for working with the abstract WebCmsAsset is WebCmsAssetRepository.

WebCmsAssets also have a sortIndex, which will initially be set to 1000. Should you create your own WebCmsAsset implementation, do note that if you use a Builder pattern, that you will need to provide the logic to set the sortIndex to 1000. (e.g. override the default value inside the builder.)

3. Linking assets

A generic WebCmsAssetLink object is available to link a WebCmsAsset to any WebCmsObject with a specific linkType demarcation. These links are mapped using WebCmsAssetLink and WebCmsAssetLinkRepository

4. WebCmsTypeSpecifier

The base class for a type is WebCmsTypeSpecifier. A type is a specification attribute for another WebCmsObject like WebCmsAsset or WebCmsComponent.

Types are simpler objects that have a unique typeKey and descriptive name. The typeKey must always be unique within all instances of that type. The typeKey is used heavily throughout code or imports for an easy - readable way of identifying a specific type.

Apart from the typeKey, a WebCmsTypeSpecifier has a collection of attributes. These are simple key/value pairs of strings that can be used for configuration and behaviour.

5. Linking types

A generic WebCmsTypeSpecifierLink object is available to link a WebCmsTypeSpecifier to any WebCmsObject with a specific linkType demarcation. These links are mapped using the WebCmsTypeSpecifierLink and WebCmsTypeSpecifierLinkRepository.

Page model

6. Overview

A WebCmsPage is a component that represents a single page in the application. It differs from an article in that the page is stand-alone, i.e. you have more control regarding the layout and the components of the page. One can use this, for example, to create about or faq pages. It is related to the publication model in that an article is contained in a page: the data is contained in the article component, but how the article is rendered is handled by the page.

6.1. Properties

Name Type Mandatory Description Default Value

Page Type

Page Type

Yes

Defines the page type of a page. Can be set during page creation but can not be changed afterwards.

Default

Title

String

Yes

The title of the page.

None

Parent

Select

No

Parent page of the page. Affects any generated URLs and (if auto-generated) the canonical path.

None

Template

String

No

The thymeleaf template of the page. The filename of the page without the extension. If none is defined the one from the page type is used.

None

Path Segment

String

No

The path segment of the page.

None

Auto create menu items

Checklist of menu names.

No

If checked, a menu item is generated for the checked menu(s).

None

There are two configurable subsections, one for URL settings and one for publication settings

6.1.1. URL settings

Field Type Mandatory Description Default Value

Path Segment

String

Yes

Path (URL) of the page.

None

Canonical path

String

Yes

FQDN of the page. Must be unique within the application.

None

Both of these can be generated manually or automatically, depending on the title and parent (and grandparent, and …​) of the page by checking the relevant checkboxes.

6.1.2. Publish settings

Field Type Mandatory Description Default Value

Published

Boolean

Yes

If the page is published (or not). Published pages are visible for regular, non-logged in users.

None

Publication Date

Date

No

The page is only visible if the access date of the file is greater than the publication date.

None

Auto-create new menu items

Boolean

Yes

If checked, creates a new menu item after creation.

False

When creating or updating the page, the following updates are done with regards to the associated URLs:

  • If the page object is saved, and the publication is in the future or not yet published, update the primary url.

  • If the page object is saved and published but the publication date is in the past, no adjustments to the primary url will happen.

This, however, can be overridden by behaviour defined in WebCmsMenu.

6.1.3. Page template

A page can optionally specify a template that should be used for rendering. If the template is left empty, the template attribute of the WebCmsPageType will be used as template for rendering instead. If the WebCmsPageType does not specify a template either, the value of module setting webCmsModule.pages.default-template will be used.

A page template will usually be resolved by the configured Spring MVC ViewResolver beans. By default page templates are expected to be Thymeleaf template files.

At startup of the application, WebCmsModule will attempt to determine the default template path of the current application. Any relative template will then be automatically prefixed with the default template path. Only templates with a specified prefix (eg. th/) are considered absolute and will be left untouched.

The default file extension .html does not need to be specified when setting the template value.

Example: MyApplication would resolve the default template path as th/my/.

  • template my-template would be resolved as th/my/template

  • template th/other-module/my-template would be resolved as th/other-module/my-template

You can manually specify the default template prefix using property webCmsModule.pages.template-prefix. See the module settings for all options you can configure if you want to change the default template resolving behaviour.

6.2. Web Components

A WebCmsPage can contain different WebCmsComponent assets. Those form the building blocks of the pages. For further information, please check the chapter on components.

6.3. URLs

A WebCmsPage can be referred to by different URLs. Please see the respective chapter for more information.

6.4. Importing a page

One can import a page by using the import infrastructure provided by the import functionality of WebCmsModule.

6.4.1. Examples

Example page

page:
  - title: Always Created Page (1)

  - objectId: "wcm:asset:page:reference-simple"
    title: Simple Page

  - objectId: "wcm:asset:page:reference-simple-child"
    title: Simple Child Page
    parent: "wcm:asset:page:reference-simple" (2)
    published: true

  - objectId: "wcm:asset:page:reference-fixed-path-segment"
    title: Fixed Path Segment Page
    parent: /simple-page (2)
    pathSegment: fixed
    publicationDate: "2017-03-14"

  - objectId: "wcm:asset:page:reference-faq"
    title: Frequently Asked Questions
    pathSegment: faq
    wcm:menu-items: (3)
      - menu: sideNav
      - menu: topNav
        title: FAQ
        path: /help/faq
        sortIndex: 10
1 Sensible defaults are used. Only title is mandatory.
2 One can refer to both the object id and the canonical path.
3 You can use this notation to manipulate the associated menu items.

6.4.2. Properties

Page properties that can be imported
Property On UI Details

title

Title

parent

Parent

Should be the canonical path or the objectId

pathSegment

Path segment

pathSegmentGenerated

Generate path segment based on title

canonicalPath

Canonical Path

canonicalPathGenerated

Generate canonical path based on title

template

Template

pageType

Page type

Only supported during creation; if you do an update where the type has been changed an exception will be thrown.

objectId

-

isPublished

Published

publicationDate

Publication Date

7. WebCmsPageType

A WebCmsPageType is used for assigning a certain type of page to a WebCmsPage. The default page type is controlled via the webCmsModule.pages.default-page-type parameter in the configuration.

7.1. Properties

Parameters
Field Required Type Description Default Value

Name

Yes

String

The name of the page type. Displayed in the drop down list when creating a new page.

None

Attributes

No

Attributes

The attributes affecting the behaviour when rendering/creating the page. Specified as key-value pairs.

None

wcm:components

No

Components

The components that are automatically generated when creating a page that uses this page type.

None

Attributes

Attribute Description

contentTemplate

The name of the container component whose components should be cloned to every page of that type. If omitted, a component called contentTemplate will be searched for.

defaultTemplate

The thymeleaf page that is used if there has not been a page specified on the page itself.

hasEndpoint

Whether or not an endpoint is defined for a page. If you disable this, the menu and URL functionality will be disabled on the front end.

isPublishable

Whether or not the page can be published.

7.2. Importing a page type

In the standard setup one can only manipulate the available page types via the import functionality. The default types are described further down. One can extrapolate any other needed page type from them.

7.2.1. Default page types

types:
  page:
    default: (1)
      name: Default
    template:
      name: Template
      attributes: (2)
        hasEndpoint: false
        isPublishable: false
1 The default page type. Notice that there are no attributes, so the default attributes specified are in effect for this type.
2 Attributes are defined as simple key-value pairs.

Another, more complex example. This page contains multiple nested containers that themselves have child components.

7.2.2. Tabbed

tabbed-page:
  name: Tabbed page
  attributes:
    template: th/cfr/tabbed-page
  wcm:components:
    content:
      componentType: container
      sortIndex: 1
      wcm:components:
        code:
          title: Code
          componentType: container
          wcm:components:
            introduction:
              title: introduction
              componentType: html
              sortIndex: 1 (2)
              content: | (1)
                <section>introduction</section>
            requirements:
              title: requirements
              componentType: html
              sortIndex: 2
              content: | (1)
                <section>requirements</section>
            browser-support:
              title: browser support
              componentType: html
              sortIndex: 3
              content: | (1)
                <section>browser support</section>
            further-reading:
              title: further reading
              componentType: html
              sortIndex: 4
              content: | (1)
                <section>further reading</section>
        documentation:
          title: Documentation
          componentType: html
          sortIndex: 2
        used-in:
          title: Used in
          componentType: html
          sortIndex: 3
1 Pre-filled content. When a page is created using this template, this data will be filled in (but can be changed by the user).
2 You need to manually set the sort order, or otherwise the default value (i.e. 0) will be filled in.

8. Web infrastructure

Any WebCmsPage will automatically create a WebCmsAssetEndpoint with generated URL values.

8.1. Default page controller model

When requesting a page endpoint a default model will be rendered:

  • the template rendered will be determined by the template property or by the WebCmsPageType if no template is set on the page itself

  • the components attached to the page will be available as page scope

  • the following model attributes will be registered:

    • page: WebCmsPage being rendered

    • asset: WebCmsPage being rendered (alias for page)

The default page model is loaded by the WebCmsPageModelLoader bean.

8.2. Custom page mapping

You can create your own page handler by using @WebCmsPageMapping annotation. The @WebCmsPageMapping annotation can be combined with other @RequestMapping annotations to create a specific match.

@WebCmsPageMapping(canonicalPath = "/my/page") (1)
public void extendSpecificPageModel( WebCmsPage page, Model model ) {
    model.addAttribute( "extraData", ... );
}

@GetMapping (2)
@WebCmsPageMapping(pageType = "static") (2)
@IgnoreEndpointModel (3)
public String renderStaticPage( WebCmsPage page, Model model ) {
    model.addAttribute( "page", page );
    return "th/my-app/static-page";
}
1 Handler method that will be used for the single page with the unique canonicalPath /my/page. The default page model will still be loaded, this handler only adds a model attribute. This handler method could optionally return a view, but since it does not, the view being rendered is still determined by the default model.
2 Handler method for a page of type static, provided the page is requested using the HTTP GET method.
3 The @IgnoreEndpointModel annotation suppresses the default page model from being loaded. The handler method should fully initialize the model required as well as return the view that should be rendered.

Publication model

WebCmsModule contains a default publication model for articles. An article can typically be pretty much any type of content, but usually it is something like a piece of news or a blog article.

  • An article is of a specific article type and belongs to a single publication.

  • A publication is of a specific publication type.

  • The publication type determines the different article types any publication of that publication type can have.

1.1. Example model

  • Publication type blog would represent a collection of blog articles

    • Article types blog and status-update would be linked to the publication type

  • Publication John’s blog would be a single instance of the blog publication type

  • Leaving on holiday today! would be an article of type status-update in John’s blog

1.2. Default model

Out of the box, WebCmsModule configures the following data:

  • publication types: news, blogs

  • article types: news, blog

  • template pages: /blog/*, /news/*

  • publications:

    • news with article type news and template page /news/*

    • blogs with article type blog and template page /blog/*

9. Domain implementation

9.1. Asset implementation

9.2. WebCmsArticle

Represents a single article. WebCmsArticle is an implementation of a publishable WebCmsAsset.

The properties title, subTitle and description are metadata properties of an article. The bulk of the article content is represented as a collection of components and can be configured on application level.

Properties articleType and publication refer to the WebCmsArticleType and WebCmsPublication of the article respectively.

See Configuring your own publication model for an example component configuration.

An article is considered an asset with an endpoint URL. When saving an article, a URL will always be created combining the title of the article with the canonical path of the publication template page.

9.3. WebCmsArticleType

Represents the specific type of an article. WebCmsArticleType is an implementation of WebCmsTypeSpecifier. The article type is used to determine the components that should be added to an article of that type.

The default components are the members of a container linked to the article type and will be cloned to every article created. The name of the default component container is contentTemplate, but the name can be configured by setting the contentTemplate attribute on the WebCmsArticleType. An article type can also use the component container from another article type. The article type to reuse the component container from can be configured by setting the parent attribute to the typeKey of the other article type.

An article is always linked to a single article type.

See Configuring your own publication model for a full example.

9.4. WebCmsPublication

Represents a named collection of articles. WebCmsPublication is an implementation of a publishable WebCmsAsset. Property publicationType refers to the WebCmsPublicationType of the publication.

Property articleTemplatePage links to a WebCmsPage that represents the template layout of the article. When saving an article, the canonicalPath of the template page will be used as pattern (usually prefix) for the article URL. The template page model will also be loaded automatically when rendering an article, see Web infrastructure for more information.

An article is always linked to a single publication.

9.5. WebCmsPublicationType

Represents the specific type of a publication. WebCmsPublicationType is an implementation of WebCmsTypeSpecifier. The publication type defines the different article types that are allowed in a publication of that type.

Services and repositories

The following repositories are available for managing the publication related domain model:

  • WebCmsPublicationTypeRepository

  • WebCmsPublicationRepository

  • WebCmsArticleTypeRepository

  • WebCmsArticleRepository

If you want to change the strategy for default components, see the WebCmsDefaultComponentsService.

10. Administrative UI

The default configuration allows managing publications and articles from the administration UI. Both article type and publication type are assumed to be installed using code.

Enabling/disabling managing of article type or publication type can be done by modifying the EntityModule configuration of WebCmsArticleType and WebCmsPublicationType.

11. Web infrastructure

Any WebCmsArticle will automatically create a WebCmsAssetEndpoint with generated URL values.

11.1. Default article controller model

When requesting an article endpoint a default model will be rendered:

  • the template rendered will be determined by the WebCmsPage that is the article template of the WebCmsPublication the article belongs to

  • the components attached to the template page will be available as page scope

  • the components attached to the article will be available as article scope, article is also the default scope

  • the following model attributes will be registered:

    • article: WebCmsArticle being rendered

    • asset: WebCmsArticle being rendered (alias for article)

    • publication: WebCmsPublication the article belongs to

    • page: WebCmsPage that is the template page for that publication

The default article model is loaded by the WebCmsArticleModelLoader bean.

11.2. Custom article mapping

You can create your own article handler by using @WebCmsArticleMapping annotation. The @WebCmsArticleMapping annotation can be combined with other @RequestMapping annotations to create a specific match.

@WebCmsArticleMapping(publicationType = "news") (1)
public void extendNewsArticleModel( WebCmsArticle article, Model model ) {
    model.addAttribute( "extraData", ... );
}

@GetMapping (2)
@WebCmsArticleMapping(publicationType = "news", articleType = "breaking-news") (2)
@IgnoreEndpointModel (3)
public String renderBreakingNews( WebCmsArticle article, Model model ) {
    model.addAttribute( "article", article );
    return "th/my-app/breaking-news";
}
1 Handler method that will be used for any article in a publication of type news, provided there is not a more specific handler (see next). The default article model will still be loaded, this handler only adds a model attribute. This handler method could optionally return a view, but since it does not, the view being rendered is still determined by the default model.
2 Handler method for an article of type breaking-news inside a news publication, provided the article is requested using the HTTP GET method.
3 The @IgnoreEndpointModel annotation suppresses the default article model from being loaded. The handler method should fully initialize the model required as well as return the view that should be rendered.

11.3. Importing data

Most domain data of the publication model can be imported using YAML. See Configuring your own publication model for a full example.

11.3.1. Configuring your own publication model

This chapter describes a full example of defining a custom publication model.

We create an article type Job which represents a particular job offering. A publication type Jobs can only contain Job articles. And our publications IT Jobs and Marketing Jobs are example collections of different job offerings.

All required configuration is shown using the YAML data structures:

Defining the article type

We create a Job article type that specifies the different content fields any Job article should have.

types:
  article: (1)
    job: (2)
      name: Job (3)
      wcm:components: (4)
        content:
          title: Job fields
          componentType: container
          wcm:components:  (5)
            company:
              title: Company
              componentType: text-field
              sortIndex: 0
            description:
              title: Job description
              componentType: rich-text
              content: <h1>@@title@@</h1>  (6)
              sortIndex: 1
            salary:
              title: Salary package
              componentType: rich-text
              sortIndex: 2
1 YAML data path types/article specifies the block defines a WebCmsArticleType
2 The type key of this WebCmsArticleType is job, and should be unique within article types. In a list YAML structure, this value would be specified using the typeKey attribute instead. For a WebCmsTypeSpecifier the type key also determines the unique object id that will be generated, in this case this would be wcm:type:article:job.
3 Descriptive name of the article type.
4 Represents the components directly linked to the WebCmsArticleType. In this case the component with name content and title Job fields. The content component represents the content template for a new article of that type. This means that when a new article is created, the content component will be cloned and attached directly to the new article.
5 Represents the collection of components that make up the members of the content component. These are the actual content fields of a job article. These fields will be directly editable in the administration UI and the sortIndex determines both rendering and editing order.
6 Special markers @@title@@, @@subTitle@@ and @@description@@ can be used to represent article properties. When creating a new article these markers will be replaced by the actual property value of the newly created article.
Defining the publication type

We create a Jobs publication type that can only hold articles with our Job article type.

types:
  publication: (1)
    jobs: (2)
      name: Jobs
      wcm:types: (3)
        - linkType: article (4)
          typeSpecifier: wcm:type:article:job  (5)
1 YAML data path types/publication specifies the block defines a WebCmsPublicationType
2 The type key of this WebCmsPublicationType, unique within publication types. In a list YAML structure, this value would be specified using the typeKey attribute instead.
3 The wcm:types attribute defines a list of other WebCmsTypeSpecifier instances linked to the current entity being imported.
4 We create an article link type. The link type can be any string value, but in case of a WebCmsPublicationType the article link type is used to refer to the WebCmsArticleType instances that are allowed in a publication of that WebCmsPublicationType.
5 The unique object id of the WebCmsArticleType that is attached to this publication type. Because a WebCmsTypeSpecifierLink can hold a reference to any WebCmsTypeSpecifier, we must use the globally unique object id.
Creating the publications

We create two publications with our Jobs types. Both publications use the same article template page for rendering the article.

assets:
  page: (1)
    - objectId: "wcm:asset:page:jobs-detail" (2)
      canonicalPath: /jobs/*
      title: Job detail page
      pageType: template (3)

  publication: (4)
    it-jobs: (5)
      name: IT Jobs
      publicationType: jobs (6)
      published: true (7)
      articleTemplatePage: /jobs/* (8)
    marketing-jobs:
      name: Marketing Jobs
      publicationType: jobs
      published: true
      articleTemplatePage: "wcm:asset:page:jobs-detail" (8)
1 YAML data path assets/page specifies the block defines a WebCmsPage. In this case we create the article template page that we’ll refer to.
2 Though not strictly required we manually define a unique object id for the page. If omitted, the canonicalPath would serve as a unique identifier for referring to our page.
3 Because our page serves as a template but it is not accessible by itself, we define it as a template page type. A template page will not get an endpoint or url created.
4 YAML data path assets/publication specifies the block defines a WebCmsPublication. In this case we create our IT Jobs and Marketing Jobs publications.
5 The publication key of this WebCmsPublication, unique within publications. In a list YAML structure, this value would be specified using the publicationKey attribute instead. We can use the publicationKey to refer to our publication in both code (eg. @WebCmsArticleMapping) and other YAML structures.
6 We refer to our newly created jobs publication type by using the publication typeKey value.
7 We set our publication as published. This ensures that all individually published articles of the publication will be actually available. If a publication is not published (offline), none of its articles will be published.
8 We link our publications to the template page we defined previously. We can use either the objectId or the canonicalPath to refer to the WebCmsPage.
Adding a sample job to our IT Jobs publication
assets:
 article: (1)
  - title: "IT Manager EMEA @ Foreach" (2)
    objectId: "wcm:asset:article:job-it-manager-emea" (3)
    publication: it-jobs (4)
    articleType: job (4)
    description: Supposed to be online until August 2017  (2)
    published: true (5)
    wcm:components: (6)
      content:
        wcm:components:
          company:
            content: Foreach
          description:
            content: A really cool job at a really great company.
          salary:
            content: Remuneration package discussable.
1 YAML data path assets/article specifies the block defines a WebCmsArticle.
2 We set some direct properties of the WebCmsArticle: title and description. Note that these are different than the content components, which could have the same name (eg. description).
3 We manually provide a unique objectId to our article. This is the only identifier for an article and is required if we ever want to update the article through data imports.
4 We create an article in our IT Jobs publication, and give it the job article type. Note that even if we were to specify a different article type, the article would still be imported. There is no hard validation during imports that only article types allowed for a publication can be imported.
5 We publish the article upon creation. This makes the article available online using a URL generated based on the article title and the article template page. In our example, the generated url for the article would be /jobs/it-manager-emea-foreach
6 We update the different content fields. As each field is a member of the linked content component, this is the same as updating individual components.

Redirects

Redirects offer you a way to specify one or more request paths that should be redirected to another path or an external url. A redirect has a destination URL and one ore more paths that should redirect to the destination. A specific HTTP status code can be configured for every path.

In the domain model, a redirect is implemented as WebCmsRemoteEndpoint. The different paths are the WebCmsUrl members of the endpoint (property urls).

12. Importing a redirect

One can import a redirect and its associated urls by using the import infrastructure provided by the import functionality of WebCms.

redirects: (1)
 - targetUrl: "http://google.com"
   wcm:urls: (2)
    - path: /path-that-should-redirect
      httpStatus: 301
1 The root element redirects indicates that the next item is going to be one (or many) WebCmsRemoteEndpoints.
2 Starts the collection of the attached urls.

Menu

A WebCmsMenu is a construct that can be used to render content resembling a menu. A single menu can have zero or more WebCmsMenuItem assets. A WebCmsMenuItem represents a link from a path in the menu to an endpoint. Like everything in WebCmsModule you need to manually define where and how you want to display the menu; there is no automatic display provided nor is there a default menu.

A menu is always built using the MenuFactory from AcrossWebModule. The WebCmsModule will intercept any menu being built, will check if there is a WebCmsMenu with that menu name, and will add all menu items if that is the case.

Usually a menu is built in a layout processor and then rendered in for example a Thymeleaf template.

Apart form items registered on a WebCmsMenu, it is perfectly to possible to add or modify items directly to the generated Menu from code.

14.1. Example building an rendering a menu

You can access the menu on your Thymeleaf template if you follow the following steps.

  • In the class where you configure your template, override the buildMenus method. In our example, we’re adding the sideNav menu to the page.

DefaultPageTemplate.java
@Component
public class DefaultPageTemplate extends LayoutTemplateProcessorAdapterBean
{
  public DefaultPageTemplate() {
   super( "default", "th/adminWebCms/layout/main" );
  }

  @Override
  protected void buildMenus( MenuFactory menuFactory ) {
   menuFactory.buildMenu( "sideNav" );
  }

  @Autowired
  public void registerAsDefaultTemplate( WebTemplateRegistry webTemplateRegistry ) {
   webTemplateRegistry.setDefaultTemplateName( "default" );
  }
}

  • Adjust your thymeleaf page. In our example we iterate over the (menu) items of the sideNav menu (and its children) to display a menu.

layout.html
<ul class="cd-accordion-menu animated">
  <li th:if="${menuGroup.hasItems() and !menuGroup.isDisabled()}" class="has-children" th:each="menuGroup : ${sideNav.items}">
     <input type="checkbox" th:if="${menuGroup.hasItems()}" th:name="${menuGroup.title}" th:id="${menuGroup.title}" th:attr="checked=${menuGroup.selected} ? 'checked'">
     <label th:for="${menuGroup.title}" th:text="${menuGroup.title}">Getting started</label>
     <ul>
        <li th:each="menuItem : ${menuGroup.items}">
           <a th:href="${menuItem.url}" th:classappend="${menuItem.selected}? 'active'"
              th:text="${menuItem.title}">About</a></li>
     </ul>
  </li>
</ul>

14.2. Generated menu items

WebCmsModule automatically adds all items of a WebCmsMenu to the menu being built with the same name.

Some particular rules apply when the menu item refers to a WebCmsEndpoint:

  • if a menu item is a WebCmsEndpoint the primary url of the endpoint will be used as url property for the menu item

  • if a menu item is a WebCmsEndpoint an attribute endpointId containing the id value of the endpoint will be added to the item

  • if a menu item is a WebCmsAssetEndpoint an additional attribute assetObjectId will be added to the item, containing the objectId value of the actual WebCmsAsset

  • if a menu item is a WebCmsAssetEndpoint and the WebCmsAsset is not published, a menu item will still be created but the value of disabled will be true

15. Properties

Table 1. Properties of a menu
Name Type Mandatory Description Default Value

Name

String

Yes

The (unique) name of the menu. Used in the thymeleaf templates to refer to the menu.

None

Description

String

No

A description of the menu.

None
Table 2. Properties of a menu item
Name Type Mandatory Description Default Value

Path

String

Yes

The path in the menu tree

None

Title

String

Yes

The title of the menu item

None

Url

String

No

The url the menu item points to. Supersedes any defined endpoint. If this is not filled in, the primary endpoint of the associated asset is used.

None

Endpoint

String

No

The endpoint this menu item points to.

None

Sort Index

Integer

Yes

The position of the item in the menu.

0

Render as submenu

Boolean

Yes

If checked, an extra property called group is set on the menu item. This can used in the Thymeleaf template to render the items in a distinct way.

False

Update automatically

Boolean

Yes

If checked and the linked endpoint gets updated, any updates will be reflected in this menu item.

False

One can import a menu and its associated items by using the import infrastructure provided by the import functionality of WebCms.

menus: (1)
  topNav: (2)
   description: Top navigation
   items: (3)
     # Register fixed controller paths
     /home: (4)
      title: Home
      url: /home
      sortIndex: 1
      asset: /extension/referenceForMenu (5)
     /categories:
      title: Categories
      group: true
      sortIndex: 2
     /categories/news:
      title: News
      url: /category/news
      sortIndex: 1
      asset: "wcm:asset:page:reference-for-menu" (5)
1 The root element menus indicates that the next item is going to be one (or many) menus.
2 The key of the YAML item is re-used as the name of the menu. Should be unique.
3 Starts the collection of the menu items.
4 The key of the YAML item is re-used as the path of the menu item.
5 If you want to set the endpoint of the item, you can use the asset keyword. It can use both the objectId (for all WebCmsAsset assets) and the canonical path (only for WebCmsPage assets).

16.1. Supported properties

This is an overview of the items that can be filled via a YAML import.

Table 3. Menu properties that can be imported
Property On UI Details

name

Name

The key of the YAML entry is used if name is not specified.

description

Description
Table 4. Menu Item properties that can be imported
Property On UI Details

path

Path

The key is used if not defined.

title

Title

asset

Endpoint

Can be an objectId (for every asset type or a canonical path (only for pages)

url

Url

sortIndex

SortIndex

group

Render as submenu

generated

Update automatically

Unresolved directive in domain-model/index.adoc - include::multi-domain/multi-domain-support.adoc[]