Vegard Solheim
May 18, 2020
(4 votes)

Customized Transformation of IContent for ContentDeliveryApi

I've created a convenient pattern to more easily customize and add additional data to the ContentApiModels delivered by ContentDeliveryApi. There are apparently some questions flying around about how to best use it, and I'll be glad to post my idea on one way to do it.

Why customize it?

The ContentDeliveryApi does much of the magic in the background (which is good), but it's not entirely obvious how to extend it in certain ways. Episerver's own Music Festival SPA demo gives a clue on how to do it with the ExtendedContentModelMapper which intercepts the transformation, but that demo only adds an URL and flattens the properties for all pages.

I've often needed to add some data that should be for all pages, and some which should be specific to some pagetypes. Essentially like a controller for ContentApi. PropertyConverters does this for properties on pages, but there was no obvious way to do the same for pages and blocks.

What does it do?

The pattern, for lack of a better word, extends the ExtendedContentModelMapper from Music Festival with the ability to add custom model converters for all types of IContent, i.e. pagetypes, mediadata, and blocks - the exception being for blocks as properties, which are handled by propertyconverters.

  1. During startup it scans the assembly for any classes implementing a specific interface.
  2. When a page is requested through ContentDeliveryApi it enters the ExtendedContentModelMapper, which finds the correct converter for that IContent.
  3. The converter uses the default IContentModelMapper for initial transformation, which makes this pattern essentially maintenance-free, then you can add any additional data to the ContentApiModel.
  4. Afterwards the resulting ContentApiModel is sent to the client as usual.

It supports an optional hierarchy so that e.g. a BasePageConverter can provide language links which all pages should have, then the specific pagetype can add additional data like user-specific information.

Being able to have all this in one spot makes it easier to handle, works essentially like a controller so that devs can follow-ish the MVC-pattern, and alleviates the need for extra web API-calls for page-specific information. Since it finds the converters through assembly scanning there's no need to register them anywhere.

Update! Dependency injection is now supported

I have now added dependency injection to the converter-classes. It uses StructureMap as the IoC tool. The code is on the master branch.

If you prefer to not have dependency injection, or plan to use another tool, the basic code is in the branch "Basic_without_dependency_injection".

Here's the code.

May 18, 2020


Jørgen Tonvang
Jørgen Tonvang May 19, 2020 10:08 AM

Once you start implementing more complex Episerver solutions/SPAs based on Episerver, this is super useful. Great work!

Please login to comment.
Latest blogs
Migrating from Providers to CMS 12 ASP.NET Identity with cookie tweaks

Notes on migrating a multi-site from Membership and Role Providers to ASP.NET Identity and changing cookie options dynamically.

Johan Kronberg | Jan 30, 2023 | Syndicated blog

Integrating generative AI in Optimizely CMS: A quick test with OpenAI

Some of the new AI services have received a lot of attention recently. Can you integrate them in Optimizely CMS? Of course, you can!

Tomas Hensrud Gulla | Jan 30, 2023 | Syndicated blog

When best practice isn't the best - Dependency Injection and Optimizely CMS

Some people live and breath 'best practice' development. I am not one of them. Risk is, in-experienced developers (or sometimes experienced) might...

Allan Thraen | Jan 29, 2023 | Syndicated blog

Implementing EmbeddedLocalization in Optimizely CMS 12

My previous post on translation (Translating Optimizely CMS 12 UI components) gives an overview of how to implement the FileXmlLocalizationProvider...

Eric Herlitz | Jan 27, 2023 | Syndicated blog