Quan Mai
Jun 12, 2018
  3968
(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 :) 

Please login to comment.
Latest blogs
Translating Optimizely CMS 12 UI components

Optimizely CMS 12 have been out for a while now, but still some elements haven't been properly translated resulting in a GUI defaulting to english....

Eric Herlitz | Jan 26, 2023 | Syndicated blog

Image preview in Optimizely CMS12 all properties view

With these simple steps, you can now see an Image and its Metadata, including size and dimensions, when editing an Image property in Optimizely...

Tomas Hensrud Gulla | Jan 26, 2023 | Syndicated blog

Setting up the ImageEditor in Optimizely CMS 12

Setting up certain configurations on Opimizely CMS 12 differs quite a bit from prior versions of (Episerver CMS 11 and older). Here's a small guide...

Eric Herlitz | Jan 25, 2023 | Syndicated blog

Happy Hour Returning in February

Hi everyone! It's been a while and we're excited to resume our Happy Hour in February for more learning, sharing, connecting, relaxing, and just to...

Patrick Lam | Jan 24, 2023