In memory IContentRepository – Getting a page

This post is part of a series of post where I try to implement an in memory IContentRepository. The tests for this posts are found here.

When getting a page we’re using the IContentLoader interface. In this post we’ll focus in the most simple case, to load a page by a page reference and not concern ourselves with different languages.

T Get<T>(Guid contentGuid) where T : IContentData;

The happy path

For testing purposes we have a a page of type StartPage with a content reference ID of 4. The two simplest cases of loading it is using a T that is something StartPage inherits from and using the StartPage type it self.

var page = contentRepository.Get<PageData>(new PageReference(4));
var pageTyped = contentRepository.Get<StartPage>(new PageReference(4));

So, in the least surprising event in history this returns the page either as the base type PageData or typed to our StartPage class.

Wront type constraint

Slightly more interesting is to see how it behaves when we pass a type restriction that it is not related to. Do you know what will happen without looking it up?

var pageOfWrongType = contentRepository.Get<StandardPage>(new PageReference(4));

This will throw a EPiServer.Core.TypeMismatchException with the message “Content with id ’4′ is of type ‘Castle.Proxies.StartPageProxy’ which does not inherit required type ‘EPiServerMvcSite1.Pages.StandardPage’”

None existing page

When we pass in a content reference that points to none existing content

var noneExistingPage = contentRepository.Get<StartPage>(new PageReference(8));

it will throw a EPiServer.Core.PageNotFoundException with the message “Content with id 8 was not found”, pretty straight forward.