DXA 2.2 Series - Dissecting the R2 Data Model - Part 3

A quick reminder, last time we looked at the Page model with Metadata and with Includes. This time we will take a short brake from the Page model and its variants and introduce the model of a Component.

Example 3 – Component Presentations

This example will demonstrate how the R2 Model of a Component Presentation (CP) looks like. Because this will be our first contact with CPs, I will explain all the properties just like with the initial Page’s Model in Example 0. I will cover both “Embedded” aka. “Static” Component Presentations (ECP or SCP), as well as Dynamic Component Presentations (DCP).

Tridion items used

• Schema: Schema 2 – Linked
• Design: 1 text field
• Metadata Design: 1 text field

• Component Template: Component Template 2 – Embedded
• Component Presentations based on this Component Template will be: Published Embedded on a Page
• Metadata:

1. Entity View Name: Demo:LinkedComponentView

• Component Template: Component Template 2 – Dynamic
• Component Presentations based on this Component Template will be: Published as a Dynamic Component
• Metadata:

1. Entity View Name: Demo:LinkedComponentView

• Component: Linked Component
• Content: Yes
• Metadata: Yes

Resulting JSON

You can view the full JSON for the SCP here and for the DCP here.

Breakdown

As with the Page JSON breakdown, we will again go property by property explaining what they all mean. Both variants will be analyzed in parallel and the “meaningfully different” properties, that is, properties whose difference does truly matter (unlike Template Ids, Titles and timesptamps) will be highlighted and explained.

The JSON always starts with the “Id“ of the item. If the item is a SCP, the value is a number containing the Id of the Component. If on the other hand the item is a DCP, the “Id” will have a different format consisting of the Component and Component Template Ids separated by a hyphen: “ComponentId-ComponentTemplateId”. Such and Id is called a Composite Id and is always a sure telltale that the referenced item is a DCP.

The “Id“ is followed by the “Namespace“, in this case ‘tcm’, indicating that the item in question is from Tridion Sites.

Unlike Page Models, here the “Namespace“ is not followed by “Title“. Actually, in case of CPs there is no “Title” property at all, instead the next property is “ComponentTemplate” and as the name implies contains information about the CT. A quick reminder, the Page Model contained the “PageTemplate” property in its place.

The “ComponentTemplate”, like the main item. again has some basic information listed like “Id“, “Namespace“, “Title“. This is followed by the “RevisionDate” which is basically the ‘modified date’ and the format of the Template written in the property “OutputFormat” (the Page Model had a “FileExtension” property instead). The final nested property is the “Metadata” of the Component Template which contains important information for the framework.

The following property is “Folder” containing two nested properties containing the Id and Title of the CM folder in the “Id” and “Title” properties respectively.

The next property “Content” is the actual content of the Component. If you recall the Schema had a single field ‘simpleTextField’ and in the sample Component we set this to ‘Hello World’. There are some specifics here with various field types, especially linked Components, but all of that will be explored in future examples.

Following the “Content” property, we have the “MvcData”. It serves the same purpose like in the Page Model and is populated similarly, but this time from the “ComponentTemplate”:

“The data contained within the “MvcData” is what dictates the inner routing of DXA (Pages/Regions/Entities) and is something which is also used by the built-in HTML helpers (ie. Html.DxaRegions(), HtmlDxaEntities(), etc.). This data is generated based on the Template metadata (PT or CT), though there is one exception which will be covered in due time, that is you might have guessed so far, by a different example :).”

Like with the Page Model, the value of the View is split by “:” and the value right to the symbol will be the “ViewName”. The value on the left of colon represents the “AreaName”. If there is no colon, the “AreaName” is set to the value of the “default-module” setting from the web.config

Similar to the Page Model, we have another returning property by the name of “XpmMetadata”. It again contains nested properties all related to Experience Manager. These properties are for example used by the built-in HTML helpers (ie. Html.DxaEntityMarkup() Html.DxaPageMarkup(), etc.).

There is one distinct difference between the SCP and DCP and that is the value of the “IsRepositoryPublished”. Its value is ‘true’ for DCPs and ‘false’ for SCPs.

The next property is “Metadata” which holds the actual metadata of the Component. If you recall the Schema had a single metadata field ‘metadataSimpleTextField’ and in the sample Component we set this to ‘Hello World From Metadata’. The rules on how the various types of fields are represented is the same like with the “Content” property and will be covered later.

And finally, we again have the “Schema” property, which this time represent the Id of the (Content) Schema. Just a reminder, this was the Page Schema in the Page Model.

Conclusion

In this entry, we took a quick brake from the Page Models and instead have focused on Components and as we could see, the basic structure of the JSON is quite similar to the Page’s. In the upcoming examples I will explain how various Schema fields are represented inside the “Content” and “Metadata” properties (including Component Links).

As always, if you have any questions, please don’t hesitate to get in touch.