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

Component Fields, linked Multimedia Components and Categories

A quick reminder, last time we looked at the basic Component Model and its properties. This time we will expand on the types of fields in the model, including Multimedia Component Links, but also show you a specific scenario for Text Fields backed by Categories.

Example 4 – Component Presentation With Various Fields

This example will demonstrate how the R2 Model of a Component Presentation (CP) looks like for most of the field types of a Component.

Tridion items used

As always, I will provide a detailed view of new Tridion items used by the example, the rest I will only mention.

Existing item:

• Component Template: Component Template 2 – Embedded (from Example 3)

New items:

• Embeddable Schema: Embeddable Schema 1
• Design: 1 External Link Field + 1 Multimedia Link Field

• Schema: Schema 3 - Linked 2
• Design:
• 1 Text Field
• 1 multivalue Text Field
• 1 Text Field with Rich Text Formatting
• 1 Date Field
• 1 Number Field
• 1 Embedded Schema Field (Schema: Embeddable Schema 1)
• Metadata Design:
• 1 Text Field

• Component: Example 4 (Schema: Schema 3 - Linked 2)
• Content: Yes
• Metadata: Yes

Resulting JSON

You can view the full JSON here.

Breakdown

The screenshot above (Example 4 – Resulting JSON) shows the result of previewing the Component. All besides two properties are collapsed as we have covered these in the previous example. As for the two which are left expanded, these are of interest and we shall take a closer look at them below.

Looking at the “Content” property, we can clearly see the fact (mentioned in Example 3) that the Component fields are transformed into their respective JSON representation (preserving the schema’s xml names):

• The schema contains a Text Field which is represented by a simple property of the JSON
• This is followed by a multivalue text field and this is represented with a nested property whose first property indicates the type, followed by a JSON array containing the actual values. We can observe this pattern (the “$type” property followed by values) with all complex properties inside the “Content” and “Metadata”
• Similarly to the previous one, the subsequent field which is an RTF text, is also transformed into a nested property with a similar format. The first sub-property contains the type followed by the “Fragments” property with 1 member holding the actual RTF content. I am yet to discover whether there are cases where the “Fragments” element contains more than one member, so if you have any insight about this, please do let me know :).
• The final two fields have undergone a very simple transformation and both of them are now a single property in the JSON containing the Component fields’ values, a date and number respectively

Our Component has 1 more field left which is of type Embedded:

• Embedded fields are represented by a sub-property stating the “$type” of ‘ContentModelData’ which is followed by the actual embedded fields
• The first one is and External Link Field consisting of a simple property
• The next one is a Multimedia Link field (which is in essence a type of Component Link) and as such is again transformed into a complex property consisting of various sub-properties. The properties are very similar to Pages and Component Presentations.

1. The first sub-property is the “$type” of ‘EntityModelData’, followed by the default properties “Id” and “Namespace” containing the Id of the Multimedia Component and ‘tcm’ (indicating Tridion Sites) respectively.
2. This is followed by a complex property “ComponentTemplate” which doesn’t really belong there. I will explain why it doesn’t and how come it is there nonetheless, in a dedicated blog (covering the Data Presentation topic), so for now let’s just skip this one
3. The next property is the “Folder” containing the “Id” and “Title” of the Folder in which the Multimedia Component resides
4. Instead of the “Content” property, Multimedia Components have “BinaryContent” containing properties which define the binary, like the “Url”, “Filename”, “FileSize” and “MimeType”. Because we have previewed the Component instead of publishing, the Url starts with ‘/Preview’
5. The last property “SchemaId” contains the Multimedia Component’s Multimedia Schemas Id

The remainder of the two properties of interest is the “Metadata”, but since our Metadata Design of the Schema is very simple, the JSON doesn’t contain anything interesting. What’s worth mentioning that this property behaves the same way as the “Content”. That is, the Metadata Schema fields are represented the same way as regular content fields.

Example 5 – Component Presentation With Component Link and Category Text Fields

The last example in this topic will cover Component Links and Text Fields if the field values are selected from a Category. For the Category we will have 2 variants.

Tridion items used

As always, I will provide a detailed view of new Tridion items used by the example, the rest I will only mention.

Existing item:

• Component Template: Component Template 2 – Embedded (from Example 3)
• Schema: Schema 3 - Linked 2

New items:

• Category: Category 1 – Publishable
• Publishable: Yes
• Keywords: ‘Keyword 1 - From Category 1 (Publishable)’ and ‘Keyword 2 - From Category 1 (Publishable)’

• Category: Category 2 - NonPublishable
• Publishable: No
• Keywords: ‘Keyword 1 - From Category 2 (NonPublishable)’ and ‘Keyword 2 - From Category 2 (NonPublishable)’

• Schema: Schema 1 - Linking
• Design:
• 1 Text Field from Category ‘Category 1 – Publishable’
• 1 Text Field from Category ‘Category 2 - NonPublishable’
• 1 Component Link Field (Schema: Schema 3 - Linked 2)
• Metadata Design: Empty
• 1 Text Field

• Component: Example 5 (Schema: Schema 1 - Linking)
• Content: Yes
• Metadata: No

Resulting JSON

You can view the full JSON here.

Breakdown

The screenshot above (Example 5 – Resulting JSON) shows the result of previewing the Component. All properties besides one are collapsed as we have covered all of those in previous example. Actually, we also covered the “Content” property, just not these types of fields yet. Let’s remedy that shall we?

The first two properties of the “Content” are text fields but unlike before, this time they are populated from Keywords. In the example we have two such fields, one which takes its value from a Keyword belonging to a Category which is Publishable, and the other from a non-publishable Category. In the JSON, both are represented by a complex property consisting of the “$type” sub-property of ‘KeywordModelData’, followed by some additional sub-properties whose number depends on the type of Category:

• The Keyword from the publishable Category only has the “Id” of the Keyword and “Namespace” set to ‘tcm’. However, this is insufficient information for the DXA Model Builders to construct the appropriate Model (KeywordModel). The rest of the properties are dynamically retrieved by the Model Service (extension) when a Component or Page with such Keywords is requested. With this mechanism, the published data size is smaller and any updates to the Keywords (followed by the Category republish), are reflected in the Components and Pages which use said Keywords without the need to republish them (Components and Pages). Kind of like DCPs, but for Keywords. The tradeoff is a small computational and data retrieval effort inside the Content Service (which is of course cashed).
• Unlike the previous variant, the Keyword from the non-publishable Category has all the needed properties inside the JSON. This is required because the Category is not published, hence the Keyword data is not available on the CD side. In this scenario, all the necessary information about the Keyword is extracted and embedded during publish time. There are the regular “Id” and “Namespace”, followed by the Keyword’s “Title”, “Description” and “Key”. The final property is the “TaxonomyId” which contains the Category Id.

Needless to say, with this approach any updates to these Keywords requires a Component / Page republish for the changes to be reflected.

The last schema field of our Component is a Component Link Field containing the Component we analyzed in Example 4. Linked Components are embedded into the parent Component’s JSON with some minor differences in the properties compared to them being standalone CPs. We can clearly see this in the image below, on the left we have the Component from Example 4 embedded, while on the right I have copied the full JSON of Example 4. The differences are highlighted with yellow. We can see that if a Component is linked, it is easily recognizable by the “$type” property of ‘EntityModelData’. One other big difference is in the “ComponentTemplate”, on the right we have the already explained regular properties of the CT, while on the left we can see something strange. Again, let’s ignore this for now as I shall be covering this in a distinct topic. The last two differences are the absence of the “MvcData” and “XpmMetadata” properties. All the rest are exactly the same and thus I kept them collapsed for simplicity’s sake.

For completeness’ sake, the statement that linked Component are simply embedded is not always true, but this is related to that strange “ComponentTemplate” we keep seeing and is a topic on its own.

Conclusion

In this entry, we took a closer look at various Component fields including Component and Multimedia Component links. In the upcoming examples, we will look at how CPs are represented in a Page Model whilst also covering some other related topics.

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