Try our conversational search powered by Generative AI!

Quan Mai
Jun 12, 2018
  4466
(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
New Series: Building a .NET Core headless site on Optimizely Graph and SaaS CMS

Welcome to this new multi-post series where you can follow along as I indulge in yet another crazy experiment: Can we make our beloved Alloy site r...

Allan Thraen | Jun 14, 2024 | Syndicated blog

Inspect In Index is finally back

EPiCode.InspectInIndex was released 9 years ago . The Search and Navigation addon is now finally upgraded to support Optimizely CMS 12....

Haakon Peder Haugsten | Jun 14, 2024

Change the IP HTTP Header used for geo-lookup in Application Insights

.

Johan Kronberg | Jun 10, 2024 | Syndicated blog

Copying property values

In this article I’d like to show simple Edit Mode extension for copying property values to other language versions. In one of my previous blogposts...

Grzegorz Wiecheć | Jun 8, 2024 | Syndicated blog