DXA 2 promises to publish less verbose JSON, sending smaller JSON items into the Publishing Queue and therefore speeding up our publish times.  It will also consume less space in the Broker DB.  So they say!  But, what does the new and old JSON look like and is it much lighter?  In this article I’ll highlight only the diffs between the rendering of a Keyword field JSON and Textfield JSON.  And, you might be wondering why I even care (aside from curiosity), but I’ve built a TBB that amends the Published DXA JSON and injects Structure Group Metadata fields masquerading as Page Metadata fields (in the JSON) and therefore available to our DXA Frontend WebApp.  OK, so here it is:

DXA 1.7 Keyword Field

"people": {
 "Name": "people",
 "Values": [ "Public and Member Communications", "Public Interest people", "Publications and Databases" ],
 "NumericValues": [ ],
 "DateTimeValues": [ ],
 "LinkedComponentValues": [ ],
 "FieldType": 3,
 "CategoryName": "people List",
 "CategoryId": "tcm:11-11393-512",
 "XPath": "Metadata/custom:people",
 "KeywordValues": [
 {
 "IsRoot": false,
 "IsAbstract": false,
 "Description": "",
 "Key": "",
 "TaxonomyId": "tcm:11-11393-512",
 "Path": "\\people List\\Public and Member Communications",
 "RelatedKeywords": [ ],
 "ParentKeywords": [ ],
 "MetadataFields": { },
 "Id": "tcm:11-106852-1024",
 "Title": "Public and Member Communications"
 },
 {
 "IsRoot": false,
 "IsAbstract": false,
 "Description": "",
 "Key": "",
 "TaxonomyId": "tcm:11-11393-512",
 "Path": "\\people List\\Public Interest people",
 "RelatedKeywords": [ ],
 "ParentKeywords": [ ],
 "MetadataFields": { },
 "Id": "tcm:11-106848-1024",
 "Title": "Public Interest people"
 },
 {
 "IsRoot": false,
 "IsAbstract": false,
 "Description": "",
 "Key": "",
 "TaxonomyId": "tcm:11-11393-512",
 "Path": "\\people List\\Publications and Databases",
 "RelatedKeywords": [ ],
 "ParentKeywords": [ ],
 "MetadataFields": { },
 "Id": "tcm:11-106853-1024",
 "Title": "Publications and Databases"
 }
 ]
}

DXA 2.0 Keyword Field

"people": {
 "$type": "KeywordModelData[]",
 "$values": [
 {
 "Id": "106852"
 },
 {
 "Id": "106848"
 },
 {
 "Id": "106853"
 }
 ]
},

DXA 1.7 Text Field

"language": {
 "Name": "language",
 "Values": [ "English" ],
 "NumericValues": [ ],
 "DateTimeValues": [ ],
 "LinkedComponentValues": [ ],
 "FieldType": 0,
 "XPath": "Metadata/custom:language",
 "KeywordValues": [ ]
},

DXA 2.0 Text Field

"language": "English",

Summary

So, there we have it, the new DXA 2.0 JSON delivers what it promises – much leaner and meaner JSON for the benefit of us all.

Sometimes you may wish to add additional content into the default DXA JSON content that is published to the Broker that are not part of the default Component Fields. In my situation I would like to have fields from the Page and Structure Group Metadata available in my DXA view. While using DXA 1.7 there is no out of the box, or ‘accelerated’, way to do this. My idea is to create an additional C# TBB, and in that access the DXA JSON and also add a field to it. The advantage to this approach is that the additional field will be seen by the DXA runtime as a Page Metadata field, and therefore serialized and available to us in the View without doing anything special on the DXA Frontend Webapp.

In this post I will share a sample app I used to access the DXA JSON and add an additional property into the MetadataFields collection. It was quite tricky to get this code to work, as we need to use the ‘dynamic’ type in C#, and this is without intellisense, so finding the appropriate methods and properties to use was a bit of a challenge. You will need to add the Newtonsoft JSON library from Nuget to get the code to work.

In a future article I will share more about the C# TBB that uses this code. The dxa.json file is the output of the Generate Dynamic Page (DXA) TBB form Template Builder. Also, in the code below, I only show an example for a text field, and I also do not product the JSON for XPM – as I have no intention of using XPM on these ‘fake’ Page Metadata fields.

using System.Collections.Generic;
using Newtonsoft.Json.Linq;
using System;

namespace temp1
{
    class Program
    {
        static void Main(string[] args)
        {
            string text = System.IO.File.ReadAllText(@"C:\RC\dxa.json");
            dynamic jsonObject = JObject.Parse(text);
            dynamic meta = jsonObject.MetadataFields;

            dynamic zone = new JObject();
            zone.Name = "zone";

            List values = new List()
            {
               "value"
            };

            dynamic array = JArray.FromObject(values);
            zone.Values = array;
            zone.FieldType = 0;  // text type, need to change if other field type

            // title is a mandatory metadata field on the Page
            meta.Property("title").AddAfterSelf(new JProperty("zone", zone));

            Console.ReadLine();
        }
    }
}

DXA 1.7 includes Template Building Blocks that help us publish content in JSON format to the Tridion Broker database. One of these Template Building Blocks is the GenerateSitemap.tbb that publishes all Pages and Structure Groups from your entire website as 1 JSON file. You might think this sounds great – and it really is – one great big file! However, if you have thousands of Pages and hundreds of Structure Groups, you might just be interested to publish the Structure Group info and Index pages in the Navigation JSON file. In this short post I’ll share the code I used to get started.  If this is your first time hacking the DXA Template Building Blocks, you might want to check out my post here on how to get started compiling the DXA TBBs.

The idea here is to create a new TBB, GenerateNavigation tbb, that publishes just the Structure Groups and index pages.

I’ve re-used the entire GenerateSitempa.tbb file and just modified one of the methods.

Here is my new modified method and also the call to it.

public override void Transform(Engine engine, Package package)
{
    Initialize(engine, package);

    _config = GetNavigationConfiguration(GetComponent());
   
    SitemapItem sitemap = GenerateStructureGroupNavigation(Publication.RootStructureGroup, true);

    string sitemapJson = JsonSerialize(sitemap);

    package.PushItem(Package.OutputName, package.CreateStringItem(ContentType.Text, sitemapJson));
}

private SitemapItem GenerateStructureGroupNavigation(StructureGroup structureGroup, bool structureGroupsOnly)
{
    SitemapItem result = new SitemapItem
    {
        Id = structureGroup.Id,
        Title = GetNavigationTitle(structureGroup),
        Url = System.Web.HttpUtility.UrlDecode(structureGroup.PublishLocationUrl),
        Type = ItemType.StructureGroup.ToString(),
        Visible = IsVisible(structureGroup.Title)
    };

   
    foreach (RepositoryLocalObject item in structureGroup.GetItems().Where(i => !i.Title.StartsWith("_")).OrderBy(i => i.Title))
    {
        SitemapItem childSitemapItem = null;
        Page page = item as Page;
        if (page != null)
        {
            if (page.FileName == "index")  // Add pages with the name index - APA Custom
            {
                if (!IsPublished(page))
                {
                    continue;
                }

                childSitemapItem = new SitemapItem
                {
                    Id = page.Id,
                    Title = GetNavigationTitle(page),
                    Url = GetUrl(page),
                    Type = ItemType.Page.ToString(),
                    PublishedDate = GetPublishedDate(page, Engine.PublishingContext.TargetType),
                    Visible = IsVisible(page.Title)
                };
            }
        }
        else
        {
            childSitemapItem = GenerateStructureGroupNavigation((StructureGroup)item, true);
        }
        if(childSitemapItem != null)
        {
            result.Items.Add(childSitemapItem);
        }
    }
   
    return result;
}

In this article I’ll discuss the process of downloading and compiling the Default DXA TBBs, and then we can add our new TBB to the default DXA project.  You might want to do this so you can add another TBB into the DXA project, or to modify one of the existing ones.  However, the DXA team would like to get your updates as a Pull Request so they can make the existing ones even better.

Modifying the Default DXA TBBs

1. Download the sources (with the correct version selected) from here: https://github.com/sdl/dxa-content-management

2. Open the solution and look at the Properties, then Build Events. There is a post-build event with the following:
“C:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe” ^
/out:Sdl.Web.Tridion.Templates.merged.dll ^
/targetplatform:v4 ^
/lib:C:\_references\cm-8.1 ^
Sdl.Web.Tridion.Templates.dll DD4T.ContentModel.Contracts.dll DD4T.ContentModel.dll DD4T.Serialization.dll DD4T.Templates.Base.dll Newtonsoft.Json.dll /log

3. Check if you have ILMerge.exe in the folder C:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe. If not, then download here: https://www.microsoft.com/en-us/download/details.aspx?id=17630

4. Copy the DLLs from the Tridion/bin/client folder to a folder on your local drive. I prefer to keep the references as part of the project. For example, I use: C:\RC\dxa-tbbs-1.7\dxa-content-management-release-1.7\references

All DLLs are required, even the ECL ones, and they’re all listed on the README here: https://github.com/sdl/dxa-content-management. If you don’t have ECL installed, you’ll need to install it at least on your Dev server to get the DLLs. You can use the Add/Remove Programs and ‘Change’ option to add the feature. Restart required, because the GUI will complain after you install the ECL without a restart.  Also, The DLLs after the path are expected to be found in the /bin/debug folder of the project.

5. Build

Potential errors:
1. Error code 3 – This means Visual Studio cannot find ILMerge.exe
2. Error code 1 – It cannot find the DLLs folder specified in the post-build script

Tips:
– Use the /log switch in the post-build command to write the output to the ‘Output’ window for easier debugging

Happy hacking!

When creating a new DXA (1.7) Web Application we can use DXA Core sample website to get started or we can start fresh, and build it from ground up using the NuGet packages.  In a recent project we wanted to start fresh, only using the framework itself and not any of the samples provided OOTB.  While some may say we lose the ‘acceleration’ by taking this path, others could argue that in most client applications they prefer to have a clean solution where they know what all the code does, and why, and have no extra stuff that is not needed or used inside.  So, anyways, we decided to take the high road and start from a ‘file, new project’ approach.  It hasn’t been easy, but it’s been real.

While making the new project you will have almost everything you need – except for one very important and not included DLL – the SDL.Web.Tridion.dll file.  This is referenced from the Unity IoC container…and you can see it in the Unity.config file.  It is not referenced in the project references.  When you don’t have this file in the /bin folder, you will get the following error message:

The type name or alias DefaultCacheProvider could not be resolved. 
Please check your configuration file and verify this type name.

The solution is quite simple, but can be deceiving.  The DXA Sample Project .csproj file includes a very important command to tell the project to copy the DLL.

 <Target Name="BeforeBuild">
 <CallTarget Targets="CopyDxaFrameworkLibsToOutput" />
 </Target>

In your own .csproj file, copy the above config anywhere on the top level.  I placed mine before the final closing </Project> tag.  Now, re-open the project in Visual Studio and build, and you should see the friendly SDL.Web.Tridion.dll file in the bin folder and your website will be happy again.