SaaS CMS has officially launched! Learn more now.

Quan Mai
Jun 12, 2018
  4484
(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
Optimizely release SaaS CMS

Discover the future of content management with Optimizely SaaS CMS. Enjoy seamless updates, reduced costs, and enhanced flexibility for developers...

Andy Blyth | Jul 17, 2024 | Syndicated blog

A day in the life of an Optimizely Developer - London Meetup 2024

Hello and welcome to another instalment of A Day In The Life Of An Optimizely Developer. Last night (11th July 2024) I was excited to have attended...

Graham Carr | Jul 16, 2024

Creating Custom Actors for Optimizely Forms

Optimizely Forms is a powerful tool for creating web forms for various purposes such as registrations, job applications, surveys, etc. By default,...

Nahid | Jul 16, 2024

Optimizely SaaS CMS Concepts and Terminologies

Whether you're a new user of Optimizely CMS or a veteran who have been through the evolution of it, the SaaS CMS is bringing some new concepts and...

Patrick Lam | Jul 15, 2024