Hierarchies
On this page we'll explain how to create content type schemas so that you can add content items to hierarchies, how to sort hierarchy nodes and what information you can retrieve using the filter API.
We've also included several examples: a simple hierarchy, a hierarchy that contains multiple content types and a hierarchy that is used to tag content. The examples are all included in the schema example templates in the Dynamic Content app, so it's easy to add them to your hub. See the example schemas section for more details.
For more information about the hierarchy user interface see the working with hierarchies page.
About hierarchiesLink copied!
Hierarchies allow you to model tree structures of content. A hierarchy is a natural way of using a tree structure to represent the relationship between objects. It might be a page structure for a website, a list of worldwide store locations organised by country and city, a structured list of product content, app settings or a list of ingredients and meal types for a recipe site. Hierarchies lend themselves to many use cases.
In Dynamic Content, a hierarchy provides a new way to link content items together. The content items in a hierarchy are normal content items that have relationships to each other. Because they are normal content items, you can work with these content items independently and manage and publish items in the normal way. The main difference is that a content item that is part of a hierarchy will have a relationship with its parent.
The example below shows one possible use case, a website menu that's built from a hierarchy. On the left you can see the hierarchy as modelled in Dynamic Content. Users can see at a glance how the website is structured and where content should be displayed. On the right is how the hierarchy is consumed in the app, providing the structure for the site navigation.
Hierarchies let users see the whole context. It might be a page or website layout, a buyer's guide or a list of tags to apply to blog posts. The user interface makes it easy to see all of the tree, and decide where to add and remove nodes if they need to.
Creating a schema for a hierarchy nodeLink copied!
A hierarchy is a tree of nodes, each of which is a content item. Each node can have descendants, or child nodes. You can model a hierarchy in which all nodes are the same content type, or choose to define your hierarchy so it can contain items of multiple content types.
In each content type schema that defines a content item that can be added as a node to a hierarchy, you will need to specify the content types of the items that can be added as child nodes. To do this you will make use of Amplience specific extensions to the JSON Schema standard.
Including the hierarchy definitionsLink copied!
In your schema core definitions you will need to include the hierarchy definitions as follows:
Your schema will now look something like:
The hierarchy traitLink copied!
The trait
keyword is an Amplience specific keyword that is used to include additional information about a schema. By including trait:hierarchy
you can specify that a content item created from this schema can be added to a hierarchy. You also provide a childContentTypes
array that defines the type of content items that can be added as child nodes. You can leave this array blank if you want a node created from the schema to be a leaf node with no children.
In the example shown below, we are modelling a hierarchy for a site menu. Each node in the hierarchy will be the same content type, so we just include the schema itself in the array. Only content items created from the schema registered with the URL https://example.com/site-menu-item
can be added as children.
The schema editor includes shortcuts to make it easier to add traits to your schemas.
If you change a schema to include the hierarchy-trait
object, any content items created with the schema prior to the change will need to be converted to reflect the update to being hierarchical content. Your users will be notified if a content item needs converting. See Converting items for use with hierarchies.
ExamplesLink copied!
Example 1: The site menuLink copied!
The simple example shown below is a simple hierarchy representing the menu for a website, including sections for mens, womens, electricals and a blog.
Each node in the hierarchy will be a site-menu-item content item, so the childContentTypes
array in our schema will include a single entry for the https://example.com/site-menu-item
content type schema.
Because hierarchies are just content items, you can link all or part of a hierarchy to another content item with a content-link or content-reference. For example, we could assign a category such as electricals to a banner so that appropriate content is shown when the user browses to each section of the site.
The schema also includes a title and a description for each section. The complete schema is shown below.
The filter API can be used to traverse the tree and find the children of each node.
Example 2: multiple content types: the page hierarchyLink copied!
This more advanced example makes use of two content types to implement an ideas and advice section on a website.
The page-hierarchy content type (1 in the image above) represents a category such as "Lighting and electrical" or "Heating and plumbing". It contains a title, description, image and a ranking. The page-hierarchy-node content type (2 in the image above) is the help page itself, including content such as text and images.
The start of the page-hierarchy schema is shown below. The childContentTypes
array in the trait:hierarchy
object contains two items: the page-hierarchy and the page-hierarchy-node. This is because we want to be able to add one category as a child of another and to add the help pages as children of a category.
The page-hierarchy schemaLink copied!
The page-hierarchy-node schemaLink copied!
Note that for the page-hierarchy-node schema the childContentTypes
array is empty because we don't want to add any children to page hierarchy nodes.
Example 3: using a hierarchy to tag content: the ingredients hierarchyLink copied!
In this example an ingredients hierarchy is used to tag recipes. There are 2 content type schemas: the ingredients hierarchy and the recipe schema which uses an array of content types to allow the user to choose one or more items from the hierarchy. This puts the user in control by allowing recipes to be tagged dynamically rather than having to choose from a preset list of values.
The recipe content item tagged with multiple items from the hierarchy is shown below. Note that this schema makes use of the hierarchy extension to make it easy to browse and add items from a hierarchy rather than a flat view of content items.
The ingredients
property in the recipe schema is an array of content links of the ingredients-list type. Users can choose one or more ingredients to tag the recipe. A search index could then be used to allow the user to find recipes which have been tagged with their chosen ingredients.
Sorting nodesLink copied!
By default, nodes will be shown in the order in which they are added, but you can define a sort order to specify a property that will be used for sorting.
To define a sort order, include trait:sortable
in your schema and specify one or more properties to use for sorting in the paths
array. The sort order is specified in JSON pointer format.
In this example we will sort the hierarchy tree using the title of each content item. The children of a node will be sorted in ascending order by the title
property.
In the page-hierarchy schema we've included a ranking property that allows the user to control the order in which nodes are sorted. The ranking is included in the sort, so nodes will be sorted in ascending order of ranking and, if the ranking is equal, the title will be used.
Using hierarchies with the Content Delivery APILink copied!
When you publish a hierarchy node you can choose whether to publish it on its own or together with its dependents. The Content Delivery API includes some additional information about a node under the hierarchy
element. Here's an example of the content returned for the root of the hierarchy- that is the node that has no parent item. You can see that root
is set to true.
Here's the content returned for an item named "Clearance", you will notice that this includes a parentId
element. This is the node's immediate parent, in this case the root node shown above. You can use the parentId
to traverse back up the tree or with the filter API to find the immediate children of the parent.
Use the Hierarchy API to find all descendants of the specified node, which can be the entire hierarchy or just a part of it.
Retrieving all descendants of a hierarchy nodeLink copied!
The Hierarchy API allows you to retrieve all descendants of a specified node in a hierarchy. The following example shows how to retrieve all descendants of the node with the content item id 4c67ca5a-6050-490a-9859-be20e81ac89d
to a depth of 3 levels.
You can see the response to this request by expanding the section below.
Example response from the Hierarchy API
Listing immediate children of a hierarchy nodeLink copied!
Using the filter API you can list all the children of a specified parent node by setting the filter path to /_meta/hierarchy/parentId
,as shown in the content returned from the Delivery API, and setting the parent id to the deliveryId
of the item whose children you want to return. You can use the Hierarchy API to return all children in all levels of a hierarchy.
In the example filter API request shown below we are requesting all the children of the hierarchy node with the id "b158fe6b-fe4b-46e3-92c5-33f8a4e5675c". Note that just the immediate children will be returned.
Try it outLink copied!
To try out the filter request use the following cURL.
An example response is shown below. These are the items that have the node with the id "b158fe6b-fe4b-46e3-92c5-33f8a4e5675c" as their parent.
Removing a node from a hierarchyLink copied!
When you remove a node from a hierarchy, the link between the node and its parent is still there in the published version of your content. In order to ensure that the node is not included when you list all children of its parent you need to either:
- Remove the node from the hierarchy and re-publish it. This is the approach to use if you still want to retrieve the published version of the content item.
or
- If you no longer need the content item: unpublish the node and then remove it from the hierarchy.
Removing and republishing the nodeLink copied!
In the example below we're removing the "Bathroom" node from its hierarchy.
The bathroom node is no longer part of the hierarchy, but as you can see from the JSON returned by the Content Delivery 2 API, the parentId still contains the value of its previous parent node.
When the item is re-published, the parentId will not longer be included in the JSON response and the item will no longer be returned as part of the hierarchy.
Unpublishing and removing the nodeLink copied!
If you no longer need to retrieve the node using its production Content Delivery URL, you can use the unpublish feature.
In the example below, we no longer want the Dishwashers node to be part of the hierarchy. To unpublished the node, select it in the hierarchy so the content item the node represents is shown on the content form. Choose "Unpublish" from the "Save" menu to unpublish the item.
If you're no longer using the item, you may want to archive it.
After it is unpublished, the item will no longer be returned if we query all published children of its parent (in this case the Electricals node). However, it will still be returned when you query its parent using the virtual staging URL.
To remove the item from the hierarchy and the link to its parent, click the node in the hierarchy browser and choose "Remove node" from its menu.
Implementing an isActive flagLink copied!
Another approach you can use, if you're implementing something like a page hierarchy, is to include an "isActive" flag in the Content Type schema that you can use with the filter API to return only those nodes that are marked as active. This allows the user to choose which nodes will be returned.
The hierarchy chooser extensionLink copied!
The hierarchy content field extension allows users to browse and add content items from a hierarchy rather than having to find these items in the Content Library. In the example of the recipe hierarchy, by using the hierarchy extension, it's easy to to browse and add multiple ingredients.
To use the hierarchy extension you need to include the content item id of the hierarchy node from which the hierarchy can be browsed in the extension parms. You can find the content item id from the properties pane in the content form, as shown in the image below.
The ingredients
property shown below uses the extension registered as "hierarchy-extension" and passes the id of the root node of the ingredients hierarchy- the content item named "Ingredients".
Registering the hierarchy chooser extensionLink copied!
To register the hierarchy extension, go the development home page and click the extensions icon, or choose "Extensions" from the Development menu. Click the "Register extension" button.
In the registration window, choose "Content field" as the category.
Add a label and name. The name will be used as the value of the "name" field in the
ui:extension
section of a property that uses the extension. In theingredients
property shown above the extension is named "hierarchy-extension".Enter
https://hierarchy-chooser.extensions.content.amplience.net/
as the URL.Click the "Permissions" tab to set the extension permissions. Set the "Read access" and "Allow same origin" permissions.
You can specify additional parameters from the "Installation parameters" tab or add them directly in your schema. The available parameters are as follows:
Parameter | Description | Required / Optional |
---|---|---|
nodeId | The content item id of the item to use as the root of the hierarchy | Required |
type | The display size of each node: large, small or chip | Optional. The default is "large" |
When you've finished setting up the extension, click "Save" and the extension will be registered and available to include in your schemas.
Example schemasLink copied!
The schemas used in this page are all included in the schema example templates in the Dynamic Content app. Go to the using the schema examples page for more details.
You can also find the schemas on the following pages:
Adding traits in the schema editorLink copied!
The schema editor includes shortcuts for adding a trait:hierarchy
object to your schema. Just type control + space and and choose "trait:hierarchy" from the popup menu.
The trait will be added to your schema. Click inside the trait object, type control + space again and choose "childContentTypes" from the menu. Then add any content types you want to allow to be added as children of nodes of the type defined in the schema.