<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Blog posts by Vegard Solheim</title><link href="http://world.optimizely.com" /><updated>2020-05-18T12:54:36.0000000Z</updated><id>https://world.optimizely.com/blogs/vegard-solheim/</id> <generator uri="http://world.optimizely.com" version="2.0">Optimizely World</generator> <entry><title>Customized Transformation of IContent for ContentDeliveryApi</title><link href="https://world.optimizely.com/blogs/vegard-solheim/dates/2020/5/simple-customized-transformation-of-icontent-for-contentdeliveryapi/" /><id>&lt;p&gt;I&#39;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&#39;ll be glad to post my idea on one way to do it.&lt;/p&gt;
&lt;h2&gt;Why customize it?&lt;/h2&gt;
&lt;p&gt;The ContentDeliveryApi does much of the magic in the background (which is good), but it&#39;s not entirely obvious how to extend it in certain ways. Episerver&#39;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.&lt;/p&gt;
&lt;p&gt;I&#39;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.&lt;/p&gt;
&lt;h2&gt;What does it do?&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;During startup it scans the assembly for any classes implementing a specific interface.&lt;/li&gt;
&lt;li&gt;When a page is requested through ContentDeliveryApi it enters the ExtendedContentModelMapper, which finds the correct converter for that IContent.&lt;/li&gt;
&lt;li&gt;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.&lt;/li&gt;
&lt;li&gt;Afterwards the resulting ContentApiModel is sent to the client as usual.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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&#39;s no need to register them anywhere.&lt;/p&gt;
&lt;h2&gt;Update! Dependency injection is now supported&lt;/h2&gt;
&lt;p&gt;I have now added dependency injection to the converter-classes. It uses StructureMap as the IoC tool. The code is on the master branch.&lt;/p&gt;
&lt;p&gt;If you prefer to not have dependency injection, or plan to use another tool, the basic code is in the branch &quot;Basic_without_dependency_injection&quot;.&lt;/p&gt;
&lt;h3&gt;Here&#39;s the code.&lt;/h3&gt;
&lt;p&gt;&lt;a href=&quot;https://github.com/VegardSolheim/Demo-ModelConverters-Epi-ContentApi&quot;&gt;&lt;/a&gt;&lt;a href=&quot;https://github.com/VegardSolheim/Demo-ModelConverters-Epi-ContentApi&quot;&gt;https://github.com/VegardSolheim/Demo-ModelConverters-Epi-ContentApi&lt;/a&gt;&lt;/p&gt;</id><updated>2020-05-18T12:54:36.0000000Z</updated><summary type="html">Blog post</summary></entry></feed>