So I’ve been on the lookout for a good way to auto-generate Glass Mapper Models when I’m using Unicorn to sync Sitecore items for quite awhile.  I’ve finally found a mechanism that allows you to create these models relatively easily.  The thing about Leprechaun besides it’s awesome name, is that you can use it in conjunction with Rainbow (which is used by Unicorn) to Auto generate any type of file.  For example, in this article I’m going to show how you can create the models with decorators vs. the fluent API approach that you can also use with Glass Mapper, but you can definitely use Leprechaun to auto-generate fluent api models instead.

In order to get started with Leprechaun, you will need to download the latest release from Github: https://github.com/blipson89/Leprechaun/releases. At the time of this writing, I am using Version 1.0.  There is also a Nuget Package for this as well, but I found downloading the files so I could pick where it placed the files, the better approach.  Also this tool is really useful only at the developer level, and although Nuget makes it easy to pull down the code you need, I think downloading and manually installing it the better route, which I will demonstrate in this article.

Once you download the latest release you should unzip the contents and then you should have a folder that contains the source for Leprechaun.  If you open that folder you will see a bunch of dll’s and an exe called Leprechaun.Console.exe.  You should also see a folder called Scripts, this folder, contains a small sampling of scripts that can be used with the rosyln compile to auto generate a file.  By default, this includes files for Synthesis.  Instead of Synthesis, we will need to create a new file in this folder and we will call it GlassMapper.csx.  It will contain the following code:

```
// Generates Synthesis models

Log.Debug($"Emitting GlassMapper templates for {ConfigurationName}...");

public string RenderTemplates()
{
    var localCode = new System.Text.StringBuilder();

    foreach (var template in Templates)
    {
        localCode.AppendLine($@"
namespace {template.Namespace}.Models
{{
    using System;
	using System.CodeDom.Compiler;
	using System.Collections.Generic;
    using Helix.Foundation.ORM.Models;
    using Glass.Mapper.Sc.Configuration.Attributes;
    using Glass.Mapper.Sc.Fields;
	/// <summary>Controls the appearance of the inheriting template in site navigation.</summary>
	///[RepresentsSitecoreTemplateAttribute(""{{{template.Id}}}"", """", ""{ConfigurationName}"")]
    [SitecoreType(TemplateId = {template.Namespace}.Templates.{template.CodeName}.TemplateIdString)]
	public partial interface I{template.CodeName} : {GetBaseInterfaces(template)}
	{{
		{RenderInterfaceFields(template)}
	}}
}}"
        );
    }

    return localCode.ToString();
}

Code.AppendLine($@"
//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
// ReSharper disable All
{RenderTemplates()}
");

public string GetBaseInterfaces(TemplateCodeGenerationMetadata template)
{
    var bases = new System.Collections.Generic.List<string>(template.BaseTemplates.Count + 1);

    foreach (var baseTemplate in template.BaseTemplates)
    {
        bases.Add($"{baseTemplate.Namespace}.I{baseTemplate.CodeName}");
    }

    if (bases.Count == 0)
    {
        // IStandardTemplateItem only needed when no other bases exist otherwise irrelevant by transitive inheritance
        bases.Add("IGlassBase");
    }

    return string.Join(", ", bases);
}

public string RenderInterfaceFields(TemplateCodeGenerationMetadata template)
{
    var localCode = new System.Text.StringBuilder();

    foreach (var field in template.OwnFields)
    {
        localCode.AppendLine($@"
		/// <summary>{field.HelpText}</summary>
        [SitecoreField(FieldName = {template.Namespace}.Templates.{template.CodeName}.Fields.{field.CodeName}_FieldName)]
		{GetFieldType(field)} {field.CodeName} {{ get; }}");
    }

    return localCode.ToString();
}

public string GetFieldType(TemplateFieldCodeGenerationMetadata field)
{
    switch (field.Type.ToLower())
    {
        case "tristate":
            return "TriState";
        case "checkbox":
            return "bool";

        case "date":
        case "datetime":
            return "DateTime";

        case "number":
            return "float";

        case "integer":
            return "int";

        case "treelist":
        case "treelistex":
        case "treelist descriptive":
        case "checklist":
        case "multilist":
            return "IEnumerable<Guid>";

        case "grouped droplink":
        case "droplink":
        case "lookup":
        case "droptree":
        case "reference":
        case "tree":
            return "Guid";

        case "file":
            return "File";

        case "image":
            return "Image";

        case "rich text":
        case "html":
            return "string";

        case "general link":
            return "Link";

        case "single-line text":
        case "multi-line text":
        case "frame":
        case "text":
        case "memo":
        case "droplist":
        case "grouped droplist":
        case "valuelookup":
            return "string";
        default:
            return "string";
    }
}
```

We will also want to update the `Constants.csx` file.  This is a file that mimics the Template.cs file that’s used by Habitat.  We will just extend that functionality so that it contains the Template Id as a string and to change the formatting just slightly to match more to the type of constants file you might be used to seeing if you’ve ever worked with TDS and Glass Mapper, with it’s T4 templates that auto-generate the glass models.  These changes to the Constants.csx file is also required so that items in the GlassMapper.csx work correctly.  The CSX files are super easy to modify c# sharp files.  You will just be dealing with string manipulation to make you changes.

```
// Generates Glass Constants File

Log.Debug($"Emitting constants templates for {ConfigurationName}...");

public string RenderFields(TemplateCodeGenerationMetadata template)
{
	if (template.OwnFields.Length == 0)
	{
		return string.Empty;
	}

	var localCode = new System.Text.StringBuilder();

	localCode.Append($@"
			public struct Fields
			{{");

	foreach (var field in template.OwnFields)
	{
		localCode.AppendLine($@"
				public static readonly ID {field.CodeName} = new ID(""{field.Id}"");
				public const string {field.CodeName}_FieldName = ""{field.Name}"";");
	}

	localCode.Append(@"
			}");

	return localCode.ToString();
}
public string RenderTemplates()
{
	var localCode = new System.Text.StringBuilder();
	
	foreach(var template in Templates)
	{
		localCode.AppendLine($@"
		public struct {template.CodeName}
		{{
            public const string TemplateIdString = ""{template.Id}"";
			public static readonly ID TemplateId = new ID(TemplateIdString);
			{RenderFields(template)}
		}}");
	}

	return localCode.ToString();
}

Code.AppendLine($@"
namespace {GenericRootNamespace}
{{
	using global::Sitecore.Data;
	public struct Templates
	{{
		{RenderTemplates()}
	}}
}}");
```

Finally there is a Diagnostics file in that scripts folder as well.  Typically I like to leave that file in place, so that if any issues come up, I can use that as a point of reference to track down the issues.

## Solution Setup

Now that we have the csx files configured with the changes we will need to enable Glass model generation with the use of Leprechaun, the next step is to get Leprechaun up and working in our solution.  I have already configured Leprechaun in two different open source projects I have been working on listed below, if you find that it’s easier to just copy what I’ve done:

- Helix Starter Kit (w/ Unicorn and Glass)
- Helix Start Bootstrap Agency (w/ Unicorn and Glass)

To get started we need to copy the root folder we were working on earlier into our working solution.  It’s the folder that contains the Scripts folder and all of the dll’s.  We need to move that into a folder that sits in the root of our solution.  I’ve typically created a Tools folder to place this folder inside of that folder, but you can place it anywhere appropriate.

## Solution Leprechaun Structure

Once you have it placed, I typically will include the Scripts into the solution, but you don’t need to do that, if you don’t plan to customize the auto generation scripts.  You can do this by creating a new Solution Folder, in this example I called this folder CodeGen and inside I included the files from the scripts folder.

Additionally, jumping a little ahead here, but we can also pull in the Leprechaun.config that we will be describing what it is and how to configure it in the next section.  In this example, I have included it in the Configuration folder, so that it’s easy to access from the solution.

You don’t need to include any of these in the solution as well, just providing an option in case you are making frequent changes to any of these files.

The next step related to installing Leprechaun in your solution, is to configure the Leprechaun.config file.  You can pull the file from the contents you downloaded, it should exist inside the root.  Copy this file and place in the folder that is the root to the code in your solution.  It might sound a little strange to not place these configurations underneath a modules App_Config/Include, but keep in mind the Leprechaun is a Build tool and doesn’t work directly with Sitecore.  Instead it’s going to work with your Rainbow .yml files only, which Unicorn is dealing with converting the templates in your Sitecore instance and turning them into Rainbow .yml files in the file system so that they can be committed to source control.

In my solution, I placed the Leprechaun.config under ~/Helix-Starter-Kit/src/Leprechaun.config, if you want to place it somewhere else, such as under the root of the entire source, you will need to make some customization’s to the gulp script and the Leprechaun configuration, so it can find everything.

Once you have placed the Leprechaun file in the correct location, the next step is to start editing that file.  You can refer to the Leprechaun Github page for information about editing this file.  I have included my specific configurations below, that you can use in your configuration.

```
<?xml version="1.0" encoding="utf-8" ?>
<leprechaun>
	<configurations import=".\*\*\code\CodeGen.config">
		<configuration name="Helix.Base" abstract="true">
			<codeGenerator scripts="Scripts/GlassMapper.csx, Scripts/Constants.csx, Scripts/Diagnostics.csx" outputFile="$(configDirectory)\$(layer)\$(module)\code\Models\$(layer).$(module).Model.cs" />
      			<dataStore physicalRootPath="$(configDirectory)\$(layer)\$(module)\Serialization" />
      			<templatePredicate rootNamespace="Helix.$(layer).$(module)" />
		</configuration>
	</configurations>

	
	<shared name="Shared">
		<metadataGenerator type="Leprechaun.MetadataGeneration.StandardTemplateMetadataGenerator, Leprechaun" singleInstance="true" />
		<architectureValidator type="Leprechaun.Validation.StandardArchitectureValidator, Leprechaun" singleInstance="true" />
		<architectureValidatorLogger type="Leprechaun.Validation.StandardArchitectureValidatorLogger, Leprechaun" singleInstance="true" />
		<logger type="Leprechaun.Console.ConsoleLogger, Leprechaun.Console" singleInstance="true" />
		
		<rainbowSettings type="Leprechaun.Console.LeprechaunRainbowSettings, Leprechaun.Console"
						 serializationFolderPathMaxLength="110"
						 maxItemNameLengthBeforeTruncation="30"
						 singleInstance="false" />
	</shared>

	
	<defaults>
		<codeGenerator type="Leprechaun.CodeGen.Roslyn.CSharpScriptCodeGenerator, Leprechaun.CodeGen.Roslyn" singleInstance="true" />
		<dataStore physicalRootPath="$(configDirectory)\Unicorn\$(configurationName)" useDataCache="true" type="Rainbow.Storage.SerializationFileSystemDataStore, Rainbow" singleInstance="true"/>
		<templatePredicate type="Leprechaun.Filters.StandardTemplatePredicate, Leprechaun" rootNamespace="$(layer).$(module)" singleInstance="true">
			<include name="$(layer).$(module).Templates" path="/sitecore/templates/$(layer)/$(module)" />
		</templatePredicate>

		<fieldFilter type="Leprechaun.Filters.StandardFieldFilter, Leprechaun" singleInstance="true">
			
			<exclude name="__*" />
		</fieldFilter>

		<typeNameGenerator type="Leprechaun.MetadataGeneration.StandardTypeNameGenerator, Leprechaun" singleInstance="true" namespaceRootPath="/sitecore/templates/$(layer)/$(module)" />
		<templateReader type="Leprechaun.TemplateReaders.DataStoreTemplateReader, Leprechaun" singleInstance="true" />

		
		<serializationFormatter type="Rainbow.Storage.Yaml.YamlSerializationFormatter, Rainbow.Storage.Yaml" singleInstance="true">
			<fieldFormatter type="Rainbow.Formatting.FieldFormatters.MultilistFormatter, Rainbow" />
			<fieldFormatter type="Rainbow.Formatting.FieldFormatters.XmlFieldFormatter, Rainbow" />
			<fieldFormatter type="Rainbow.Formatting.FieldFormatters.CheckboxFieldFormatter, Rainbow" />
		</serializationFormatter>

		
		<rainbowFieldFilter type="Leprechaun.Filters.RainbowNullFieldFilter, Leprechaun" singleInstance="true" />

		<logger type="Leprechaun.Console.ConsoleLogger, Leprechaun.Console" singleInstance="true" />
	</defaults>
</leprechaun>
```

I’ve removed the lengthy comments from that example, but in your instance you should leave the comments to edit the configuration easier for those that are not familiar with the syntax elements of this xml document.

The last part that needs to be configured, is that each project (module in Helix) that needs code generation enabled, needs to include a CodeGen.config, by default, this configuration will be empty in most cases, and define the Layer followed by the Module name, assuming you are building using the Helix pattern.  Then the configuration will extend from the base configuration.  This is all part of the configuration enhancements that were built into Unicorn and it’s supported by Leprechaun as well.  An example below, is a CodeGen.config I’ve configured for my Navigation Feature.

```
<?xml version="1.0" encoding="utf-8" ?>

<configuration name="Feature.Navigation" extends="Helix.Base">
</configuration>
```

One thing important to note, is that is all you need, you don’t need to wrap that in a <configuration> or <leprechaun> xml element.  I struggled with that, when I first worked with this, but leaving them exactly the structure you see above, is all you need.  Keep in mind this might change in future versions, and I can confirm this is the case with Version 1.0.

## Build Process

So there are a lot of different ways you can run Leprechaun.  I chose to include it as a task in my Gulp configuration, so I could run it as needed, but I can also add the task to the VSTS Build to run that task specifically (if you are not committing the models being generated to source control).  Some of the options you have include:

You can integrate directly into the build, using a build event.
Use a Gulp Task (which is what I’m demonstrating below)
You can also create a project target.
There are examples on the source main page that provides examples to the other methods, which I will not demonstrate in this tutorial.  Below is an example of the gulp script I have configured.  Make sure you define the npm packages you will need such as gulp-exec so you can run this in your gulp file.

```
var gulp = require("gulp");
var exec = require("child_process").exec;

// Run Leprechaun to Code Generate Models
gulp.task('_Code-Generation', function(x) {
  exec('.\\Tools\Leprechaun-1.0.0\\Leprechaun.console.exe /c .\\src\\Leprechaun.config', function (err, stdout, stderr) {
    console.log(stdout);
    console.log(stderr);
    x(err);
  });
});
```

I plan to do a video/article soon on the build process using VSTS and I will showcase the configuration needed to build these on the build server, so you wouldn’t need to commit the models in your solution.

Once you’ve completed the steps above, you should be able to refresh your Task Runner Explorer, and you should now see the task for _Code-Generation.  When you run that task, it will spit out the results.  You should see that it found x number of configurations and then it will tell you it ran x number of templates.  If you are not seeing that, then you might have an issue with your source. Please feel free to reach out to me if you have issues!

How to Use Leprechaun to Auto Generate Glass Mapper Models when using Unicorn

Out of the box, Sitecore’s Html Caching is pretty powerful, but it does have some limitations. In my most recent project I found that there were some Variations of the Cache Key that would be useful in the project.  First off I want to explain exactly how Html Caching works with sitecore.  It works at the rendering level.  So you have built for example a controller rendering (Mvc), that pulls the most recent articles on your homepage.  If all you rely on to pull content is if it’s been published to your content delivery database, than all you would need in this scenario, is to mark the item as cacheable.  What this would do, is create a key, something that represents the specific rendering, and then the code would check for that specific string value key, and see if there’s html assigned to it.  If it’s the first time loading the component, it will create the cache key, and then pull the html content.  Once it has the html content, it will create html cache using the key as an identifier, and store the returned html back.

The reason that will work in that scenario is because the html cache gets completely cleared out, anytime you publish content to the content delivery server from Sitecore.  So if your article only relies on them being in content delivery server, when you do a publish of new article content (or any publish really), it will clear the html cache, and the cache will get updated to include any new articles on the next page load.

But what do you do if you rely on publishing content, not only when it’s in your content delivery server, but also on other variables.  Example in our environment, we use a Live Date, which is set to a date in the future.  For example, if you want content to show up on a specific date even after it’s already in the content delivery server, you could set this custom date to do so.  Your repositories for pulling data from Sitecore, obviously would need to check this date to ensure content would display or not.  However doing it like this creates an issue with Html Caching, because no longer does the Publish to your CD server control when content displays.  You now need to somehow clear the cache more regularly, on some form of timed interval.  You can still of course rely on publishing to the Content delivery server triggering this refresh, but if that only happen about once a week, you will need to clear your cache every 12 to 24 hours (assuming you are only using the Date field type, if you are however using date time, you might need to clear cache hourly).  Out of the box, Sitecore does not include an option to set a Timeout value, however there is a fairly easy way to update this value and provide support for it.

Out of the Box Sitecore only includes the following options:

### Caching Options

As you can see there is no way out of the box to set a Timeout value.  But you can customize the options by going to the following location: /sitecore/templates/System/Layout/Sections/Caching, which brings you to an interface you all should be familiar with.  You can specify additional fields.  Lets go ahead and create a new field called “Timeout”, which is a Single-Line text field.  Now that you have this value being stored for the rendering, you’ll need to pull it out of Sitecore when it creates the cache, so it can set the timeout value to this value, rather than the default value.

To do so, it’s pretty easy, you just need to extend the AddRecordedHtmlToCache pipeline and override the GetTimeout method.

```
using Sitecore.Mvc.Pipelines.Response.RenderRendering;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
namespace Site.Infrastructure.Pipelines.Renderings
{
    public class AddRecordedHtmlToCache : Sitecore.Mvc.Pipelines.Response.RenderRendering.AddRecordedHtmlToCache
    {
        protected override TimeSpan GetTimeout(RenderRenderingArgs args)
        {
            TimeSpan result;
            return TimeSpan.TryParse(args.Rendering.RenderingItem.InnerItem["Timeout"], out result) ? result : args.Rendering.Caching.Timeout;
        }
    }
}
```

Once you’ve done that, all you need to do is update your patch file to apply this change:

```
<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <mvc.renderRendering>
        <processor patch:instead="processor[@type='Sitecore.Mvc.Pipelines.Response.RenderRendering.AddRecordedHtmlToCache, Sitecore.Mvc']"
                   type="Site.Infrastructure.Pipelines.Renderings.AddRecordedHtmlToCache, Site.Infrastructure" />
      </mvc.renderRendering>
    </pipelines>
  </sitecore>
</configuration>
```

Alright now you should be able to set the Timeout for the html cache for your rendering.  But what if you have a controller rendering that shows a different set of article content depending on the page you are on.  For example, lets say you have a component that shows most recent by category.  Now we would still want to timeout the cache at set intervals and clear cache on publish that is standard with Sitecore, but now we would also like to vary the results by either parameters or even by url.  Now varying the rendering by rendering parameters is build into the default Sitecore Html Caching logic.  But for this example, we will pretend that doesn’t exist, also you may not want to use a rendering parameter, but just determine the category based on the current context.

Anyways, so in order to pull this off, we will need to create a new VaryBy (variation) of the cache key.  So by default a rendering will have a cache key that’s unique to the rendering.  Then you can specify variations of that cache key, so for example vary by parameter, will create varied cache key’s based on the parameters for that specific rendering.  So if you had a rendering parameter that had page size set to 10, and then another rendering of the same component on a different page set to 20, it would built a unique cache key for those two different components.  However subsequent requests to those components would render cached html.  Also if you placed a rendering on another page of the same type with the same rendering parameter values, it will pull from Cache.

So in order to create a new variation, in this example it will vary by Url, you will need to first modify the Cache template, similar to what we did for adding a Single-Line Text field called “Timeout”. You can access this template here `/sitecore/templates/System/Layout/Sections/Caching`.  You will need to create a new field called `VaryByUrl`, and it will be of type “Checkbox”.

Once that change is made you will need to then setup the code to include the additional variation types you are specifying.  To do that, you will need to extend the `GenerateCacheKey.cs` pipeline in `RenderRendering` pipeline group.

```
using Sitecore;
using Sitecore.Data.Items;
using Sitecore.Mvc.Pipelines.Response.RenderRendering;
using Sitecore.Mvc.Presentation;
using Sitecore.Web;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
namespace Site.Infrastructure.Pipelines.Renderings
{
    public class GenerateCacheKey : Sitecore.Mvc.Pipelines.Response.RenderRendering.GenerateCacheKey
    {
        private const string VARYBYURL = "VaryByUrl";
        protected override string GenerateKey(Rendering rendering, RenderRenderingArgs args)
        {
            string cacheKey = base.GenerateKey(rendering, args);
            Item renderingItem = rendering.RenderingItem.InnerItem;
 
            if (!string.IsNullOrEmpty(renderingItem[VARYBYURL]))
            {
                cacheKey += "_#url:" + Sitecore.Context.RawUrl;
            }
 
            return cacheKey;
        }
    }
}
```

And then you will just update the patch file to include this as a patch to the default Sitecore pipelines:

```
<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <mvc.renderRendering>
         <processor patch:instead="processor[@type='Sitecore.Mvc.Pipelines.Response.RenderRendering.GenerateCacheKey, Sitecore.Mvc']"
                   type="Site.Infrastructure.Pipelines.Renderings.GenerateCacheKey, Site.Infrastructure" />
      </mvc.renderRendering>
    </pipelines>
  </sitecore>
</configuration>
```

That’s it, you can use this approach to add all kinds of variations for the creation of these Sitecore Html Caching Keys.  Some other variations that you might want to have include:

- VaryByCookie
- VaryByTemplate
- VaryByContext
- VaryByRetina

Happy Coding!

Customizing Html Caching with Sitecore XM with MVC

A common topic I hear that comes up while working with Sitecore layouts and MVC (although the problem also occurs in Web Forms) is Placeholders not allowing the content editor to select a specific placeholder to add a rendering when that rendering already exists on the page. An Example being, lets say you have modeled your layouts similar to bootstrap. You’d like to have the ability to set a grid to a page, such as an 8×4 within the current row. Then you’d like to have maybe a 6×6 followed then by another 8×4. The problem with the Sitecore layout rendering engine, is that when you set an element to the placeholder “8×4.Left” for example, it doesn’t know which 8×4 to set that element to, so what would happen in this scenerio, is that you’d have the same element rendering for both 8×4’s, even though you only wanted it to show up in the first 8×4.

So for example your Device Editor (PLD) might look like this:

Layout: General

8×4 Grid – Placeholder: Page
–>Html Block – Placeholder: Grid.8×4.Left
6×6 Grid – Placeholder: Page
8×4 Grid – Placeholder: Page
–>Html Block – Placeholder: Grid.8×4.Right

What you would like is for the Html Block rendering to only show up in the area’s you’ve specified above. However the way it works out of the box with Sitecore’s Layout engine, is that the first Html Block in the example above, would be exactly where you would expect it to be.  However the second Html Block, would actually be up in the first 8×4, even though based on that order, it’s obviously you’d like to have it placed in the second 8×4 (right).

There are currently solutions out there that attempt to resolve this issue, including some of the articles below:

http://blogs.perficient.com/digitaltransformation/2012/10/17/sitecore-mvc-dynamic-placeholders/
However these article solutions, are technically dynamic, but they require the content editor to specify a number to the placeholder name (within the Content Editor).  The problem with this solution is that it requires the content editor to keep track of the numbering.  That doesn’t seem like a horrible problem if your layout is pretty simple, but can be tedious and time consuming keeping track of the numbers, especially when you start moving the renderings around, adding renderings or removing a rendering.  Below is an example of how this would look in the PLD:

Layout: General

8×4 Grid – Placeholder: Page
–>Html Block – Placeholder: Grid.8×4.Left[0]
6×6 Grid – Placeholder: Page
8×4 Grid – Placeholder: Page
–>Html Block – Placeholder: Grid.8×4.Right[1]

By using the numbering system, you are specifically telling the rendering engine that you want to for example, set the Html Block to the second ([1]) 8×4 Grid in the PLD.

But ideally, wouldn’t it be great if you could set a rendering and only need to specify it’s placeholder name, without the numbering and based on it’s order in the PLD it could logically figure out which 8×4 for example, you wanted to set the Html Block for?  Below is a solution I’ve created that will solve this issues.  It’s actually a pretty simple solution.  It works with MVC and I’ve tested it against 8.0 and 8.1 within Sitecore.

First you’ll need to create a new Extension Method (Helper) for Html.Sitecore().  This extension will take the name (string) you pass it and append the placeholder name with the unique Id of the current rendering.

```csharp
using Sitecore.Mvc.Helpers;
using Sitecore.Mvc.Presentation;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
 
namespace Site.Web.Helpers
{
    public static class SitecoreHelperExtension
    {
        public static HtmlString DynamicPlaceholder(this SitecoreHelper sitecoreHelper, string placeholderName)
        {
            Rendering currentRendering = RenderingContext.Current.Rendering;
            return sitecoreHelper.Placeholder(string.Format("{0}|{1}", placeholderName, currentRendering.UniqueId.ToString()));
        }
    }
}
```

Second you'll need to overwrite the Pipeline responsible for Rendering items for each placeholder on the page.  Use the code below to overwrite `PerformRendering.cs`:

```csharp
using Sitecore;
using Sitecore.Diagnostics;
using Sitecore.Mvc.Common;
using Sitecore.Mvc.Extensions;
using Sitecore.Mvc.Pipelines;
using Sitecore.Mvc.Pipelines.Response.RenderPlaceholder;
using Sitecore.Mvc.Pipelines.Response.RenderRendering;
using Sitecore.Mvc.Presentation;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;
using System.Threading.Tasks;
 
namespace Site.Infrastructure.Pipelines.MVC
{
    public class PerformRendering : RenderPlaceholderProcessor
    {
        private const string DYNAMIC_KEY = "{0}";
        private const string DYNAMIC_KEY_REGEX = @"(.+)_[\d\w]{8}\-([\d\w]{4}\-){3}[\d\w]{12}";
 
        public override void Process(RenderPlaceholderArgs args)
        {
            Assert.ArgumentNotNull((object)args, "args");
            this.Render(args.PlaceholderName, args.Writer, args);
        }
 
        protected virtual IEnumerable<Rendering> GetRenderings(string placeholderName, RenderPlaceholderArgs args)
        {
            Guid deviceId = this.GetPageDeviceId(args);
            var childRenderings = new List<Rendering>();
 
            if (placeholderName.Contains("|"))
            {
                string[] placeholderParts = placeholderName.Split(new[] {'|'}, StringSplitOptions.RemoveEmptyEntries);         // 0 = Placeholder Name, 1 = UniqueId (For the Current Rendering)
                
                List<Rendering> lstRenderings = args.PageContext.PageDefinition.Renderings;
 
                if (placeholderParts.Count() > 1)
                {
                    string renderingId = string.Empty;
                    bool foundCurrentRendering = false;
                    foreach (Rendering rendering in lstRenderings)
                    {
                        if (rendering.DeviceId != deviceId)
                            continue;
 
                        if (rendering.UniqueId.ToString().Equals(placeholderParts[1]) || foundCurrentRendering)
                        {
                            // Store RenderingItemPath which is common across all renderings of this type
                            if (!foundCurrentRendering)
                                renderingId = rendering.RenderingItemPath;
 
                            // Exit Foreach When Next Rendering of Same Type as the current one is found
                            if (foundCurrentRendering && rendering.RenderingItemPath.Equals(renderingId))
                                break;
 
                            // Only Add Renderings that match Placeholdername
                            if (rendering.Placeholder.Equals(placeholderParts[0]))
                            {
                                childRenderings.Add(rendering);
                            }
 
                            foundCurrentRendering = true;
                        }
                    }
                }
            }
            else
            {
                string placeholderPath = StringExtensions.OrEmpty(ObjectExtensions.ValueOrDefault<PlaceholderContext, string>(PlaceholderContext.Current, (Func<PlaceholderContext, string>)(context => context.PlaceholderPath)));
                childRenderings = Enumerable.Where<Rendering>((IEnumerable<Rendering>)args.PageContext.PageDefinition.Renderings, (Func<Rendering, bool>)(r =>
                {
                    if (!(r.DeviceId == deviceId))
                        return false;
                    if (!StringExtensions.EqualsText(r.Placeholder, placeholderName))
                        return StringExtensions.EqualsText(r.Placeholder, placeholderPath);
                    return true;
                })).ToList();
            }
 
            return childRenderings;
        }
 
        protected virtual Guid GetPageDeviceId(RenderPlaceholderArgs args)
        {
            Guid guid1 = ObjectExtensions.ValueOrDefault<Rendering, Guid>(args.OwnerRendering, (Func<Rendering, Guid>)(rendering => rendering.DeviceId));
            if (guid1 != Guid.Empty)
                return guid1;
            Guid guid2 = ObjectExtensions.ValueOrDefault<Rendering, Guid>(ObjectExtensions.ValueOrDefault<RenderingView, Rendering>(PageContext.Current.PageView as RenderingView, (Func<RenderingView, Rendering>)(view => view.Rendering)), (Func<Rendering, Guid>)(rendering => rendering.DeviceId));
            if (guid2 != Guid.Empty)
                return guid2;
            return Context.Device.ID.ToGuid();
        }
 
        protected virtual void Render(string placeholderName, TextWriter writer, RenderPlaceholderArgs args)
        {
            IEnumerable<Rendering> renderings = this.GetRenderings(placeholderName, args);
            if (renderings != null) {
                foreach (Rendering rendering in renderings)
                    PipelineService.Get().RunPipeline<RenderRenderingArgs>("mvc.renderRendering", new RenderRenderingArgs(rendering, writer));
            }
            
        }
    }
}
```

Most of the magic happens within the GetRenderings control.  It will take the current placeholder name that’s being passed in.  Keep in mind this Pipeline runs when you call Sitecore().Placeholder, so the placeholder name that is passed in, will include the placeholder name, plus the unique id of the current rendering.  Then the logic will get all the renderings for the current page (args.PageContext.PageDefinition.Renderings) and will start traversing the enumerable List of renderings.  It will not add items to be returned until it finds the rendering that matches the Unique ID of the placeholder name that you are passing in.  Once it matches the unique ID, it will get the current rendering’s RenderingItemPath, which is an ID that is common across all renderings of that same type.  It will then only add to childRenderings, the items that match the placeholder name (minus the unique id that was passed in).  It will run this logic until it finds another rendering that has the same RenderingItemPath that matches the original rendering or it runs out of renderings (whichever happens first).

Lastly, you need to make sure you patch the Sitecore.config (8.1) or Web.config (8.0 and below).  You should be able to follow the example below to do this:

```xml
<?xml version="1.0" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <mvc.renderPlaceholder>
        <processor patch:instead="processor[@type='Sitecore.Mvc.Pipelines.Response.RenderPlaceholder.PerformRendering, Sitecore.Mvc']" type="Site.Infrastructure.Pipelines.Mvc.PerformRendering, Site.Infrastructure" />
      </mvc.renderPlaceholder>
    </pipelines>
  </sitecore>
</configuration>
```

That should be it.  You can now specify placeholder names in your code, by calling the extension method we created in the first code example.  So in your General Layout, you could create one by called @Html.Sitecore().DynamicPlaceholder(“Page”).  And then in your Sitecore PLD, all you need to do is ensure you have the correct Placeholder name specified and that you have the renderings in the correct order.

Also currently there is one limitation with the current implementation, it uses a string split on the pipe character (‘|’), so if you use pipes in your placeholder names, you could experience problems.  I plan to fix this limitation in future iterations of this feature.

Happy Coding, feel free to comment if you have any questions.

Sitecore Platform DXP

How to Use Leprechaun to Auto Generate Glass Mapper Models when using Unicorn

Customizing Html Caching with Sitecore XM with MVC

True Dynamic Placeholders in MVC