Quan Mai
Jun 12, 2018
visibility 5416
star star star star star star
(5 votes)

A new open source project: CatalogContentTypeResolver

ContentReference is the centric part of Episerver, both in CMS and Commerce: it allows you to identify a content (sometimes, a specific version of a content). A majority of Episerver APIs are built around that small type: either take it as parameter, or return it as return value, or both.

As convenient as it is, ContentReference does not let you know the strongly typed type of the content it identifies (Catalog ContentReferences let you know the type of the content (Catalog, Node or Entry), but in many cases that is not enough). To find that our your only option is to load the content via IContentLoader.Get<T> and exam the content to see if it is the type you want, before proceeding.

That is of course a waste of time and memory, given that a catalog content in general can be quite big. A few loads might be OK, but if you have thousands and thousands of ContentReference waiting to be tested, the overhead will be quite significant.

Today I'm pleased to annouce that I started a small & simple open project to address that issue: CatalogContentTypeResolver. That small class will let you figure out which model content types underneath, with a very small overhead. The main API will look like this:

_contentTypeResolver.ResolveContentTypes(new[] {entryLink, nodeLink, RootCatalogLink});

So it takes an enumerable of ContentReference, and returns an IDictionary<ContentReference, ContentType> so you can use some LINQs to know which ContentReferences are of this type.

The project can be seen at https://github.com/vimvq1987/CatalogContentTypeResolver

This is a free-for-all project. You can use it in anyway you like, (except to blame me, of course), without asking for permission. This is the very first version and you are welcome to give feedback or bug reports to make it better over time.

I hope this will be useful in your Commerce projects.

I hope to go through the code in one (or more) blogpost soon, explaining why I do this and not do that. Stay tuned.

Jun 12, 2018

Comments

Marcus B
Marcus B Jun 13, 2018 12:21 AM

Nice

Thomas Schmidt
Thomas Schmidt Jun 13, 2018 05:01 PM

Very useful! On pretty much all commerce projects I have worked on we have had the need to check content types for filtering or other purposes and we had to load content here.

Small suggestion, instead of returning a IDictionary<>ContentReference, ContentType> i would return something more API friendly like a composite object. For instance a ResolvedContentReference that has two properties instead with ContentRerence and ContentType, something like:

public class ResolvedContentReference

{

   public ContentReference ContentReference {get;set;}

   public ContentType ContentType {get;set;}

}

This is much easier to extend if you need to return additional data than a dictionary.

Quan Mai
Quan Mai Jun 14, 2018 08:50 AM

It's pretty much an implementation detail. As it's open source now you are free to do what you want how you want :) 

error Please login to comment.
Latest blogs
Composition Over Inheritance: Why Your Content Contract Is Not a Base Class

Inside the structural conformance pattern in SaaS CMS — from server-side inheritance to pipeline governance. A contract in Optimizely SaaS CMS is...

Vipin Banka | Sep 19, 2026

Optimizely Opti ID Integration: Why the API Key Was Missing from the DXP Management Portal

While working on an Optimizely CMS 12 Opti ID integration recently, we ran into an issue that initially appeared to be related to SSO authenticatio...

Madhu | Sep 18, 2026 |

Extending a Contract: What You Can Override

Contracts share fields across content types — but not every field setting can be overridden. Push the same contract onto several components, and CM...

Chirag Khanna | Sep 18, 2026 |

Building a Blazor Server UI Inside the Optimizely CMS 13 Admin Shell

What I learned shipping a Blazor Server UI inside Optimizely CMS 13 — Razor components in a NuGet package, the Blazor hub next to MapContent(),...

Stanisław Szołkowski | Sep 17, 2026 |