Views: 978
Number of votes: 5
Average rating:

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.

Nice

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.

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.