TIHIDI: Hardcode Constants vs. Sitecore Configuration Factory

This blog post will go through how I setup my solution to be able to read everything I need from configuration rather than hardcoding it as part of code.

During a project, you might have the need to store Id’s or strings in your project. What ever you do, DONOT store them as part of code or in a constants file. Use Id’s over paths always.

TIHIDI: Stands for This Is How I Do It. I am going to write a series of blog posts going through how I do Sitecore related work. Hope it helps you!

In the TIHIDI post: TIHIDI: Glass Mapper with Custom Models and Mapping using Fluent Configuration, I ended up adding in the Sitecore configuration factory code to pull in the template Ids.

The concept is very similar to what Mike GoldSuit Reynolds did in one of his blog posts, which I am unable to find the link.

First lets define the interface with all the config elements we need:

using System;

namespace TIHIDI.SCExtensions.Settings
{
    public interface ITIHIDISettings
    {
        Guid CommunityChildrenTemplateId { get;  }
        Guid CommunityTypeTemplateId { get;  }
        Guid SampleCommunityTemplateId { get;  }
        Guid SampleStatusTemplateId { get;  }
    }
}

Next, lets implement a class inheriting this interface and loading the settings.

using Sitecore.Configuration;
using Sitecore.Diagnostics;
using System;

namespace TIHIDI.SCExtensions.Settings
{
    public class TIHIDISettings : ITIHIDISettings
    {
        private static volatile ITIHIDISettings current;

        private static object lockObject = new Object();

        public static ITIHIDISettings Current
        {
            get
            {
                if (current == null)
                {
                    lock (lockObject)
                    {
                        if (current == null)
                        {
                            current = CreateNewBVSettings();
                        }
                    }
                }

                return current;
            }
        }

        public Guid CommunityChildrenTemplateId { get; private set; }
        public Guid CommunityTypeTemplateId { get; private set; }
        public Guid SampleCommunityTemplateId { get; private set; }
        public Guid SampleStatusTemplateId { get; private set; }

        private static ITIHIDISettings CreateNewBVSettings()
        {
            ITIHIDISettings tihidiSettings = Factory.CreateObject("settings/tihidiSettings", true) as ITIHIDISettings;
            Assert.IsNotNull(tihidiSettings, "tihidiSettings must be set in configuration!");
            return tihidiSettings;
        }
    }
}

Finally create a custom config with the settings you need and specify type to point to the new class.


  
    
      
        {21FA0A73-BAC5-436E-9BBC-4FFCA1C79141}
        {DEA3C5F3-F610-4A10-BD61-79BA92716361}
        {4BFC250F-51B0-4BD2-8A88-F6956CD6292C}
        {6A0338A7-3497-4870-9AE3-9C2CE053A400}
      
    
  

Now that we have that all setup, we can use it in code. Here is an example in one of my Model mapping classes.

using Glass.Mapper.Sc.Maps;
using TIHIDI.Models;
using TIHIDI.Models.Templates.Data;
using TIHIDI.SCExtensions.Settings;

namespace TIHIDI.Mapping.Templates.Data
{
    public class SampleCommunityMap : SitecoreGlassMap
    {

        public override void Configure()
        {
            ITIHIDISettings settings = TIHIDISettings.Current;

            Map(x =>
            {
                ImportMap(); //import existing maps

                //you can specify the file types so that Glass can interpret them correctly
                x.Field(y => y.CommunityType).FieldType(Glass.Mapper.Sc.Configuration.SitecoreFieldType.Multilist);

                x.Field(y => y.CommunityStatus).FieldType(Glass.Mapper.Sc.Configuration.SitecoreFieldType.Droplink);

                //as for the children we can do any of the following, each has its own advantages
                //you do not necessarily have to call the attribute children

                x.Query(y => y.MyChildren)
                    .Query(string.Format("./*[@@templateid='{0}']", settings.CommunityChildrenTemplateId))
                    .IsRelative();

                x.Children(y => y.AlsoMyChildren);

                x.TemplateId(settings.SampleCommunityTemplateId); //totally optional but you can use it to enforce template id
                x.AutoMap();
            });
        }
    }
}

You are not limited to just Ids, you can use this for all your constants needs.

If you have any questions or concerns, please get in touch with me. (@akshaysura13 on twitter or on Slack).

3 thoughts on “TIHIDI: Hardcode Constants vs. Sitecore Configuration Factory”

  1. no, I believe he never ended up blogging since I was drowning him in meetings and work! 😉

  2. You can avoid creating a singleton here 🙂 use singleInstance=”true” attribute in your node. The configuration factory will do it for you.
    Also there is a ‘provider’ pattern in the configuration if you need something with static access. But I still hate everything static, I prefer to use dependency injection, initialized from configuration factory as showed in my post here https://vladimirhil.com/2016/04/16/inversion-of-control-and-dependency-management-with-sitecore-configuration-factory/

Leave a Reply

Your email address will not be published. Required fields are marked *