Asset model
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 |
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 asth/my/template
-
template
th/other-module/my-template
would be resolved asth/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 |
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 |
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 theWebCmsPageType
if notemplate
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.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 theWebCmsPublication
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
13. Overview
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.
14. Building a 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.
@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.
<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 actualWebCmsAsset
-
if a menu item is a
WebCmsAssetEndpoint
and theWebCmsAsset
is not published, a menu item will still be created but the value of disabled will betrue
15. Properties
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 |
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 |
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 |
False |
Update automatically |
Boolean |
Yes |
If checked and the linked endpoint gets updated, any updates will be reflected in this menu item. |
False |
16. Importing a menu item
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.
Property | On UI | Details |
---|---|---|
name |
Name |
The key of the YAML entry is used if name is not specified. |
description |
Description |
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[]