In SP2 of EPiServer CMS 5 R2, that is the latest currently released version, two new methods with a bunch of overloads where added to DataFactory, GetPage<T>() and GetChildren<T>(). They where added to support Fredrik Tjärnbergs Page Type Tool and where implemented using another newly added method, PageData.ShallowCopy<T>(). Their implementation is such that if you do something like the code below GetPage<T>() will always return an instance of the requested type:
MyPageType page = DataFactory.Instance.GetPage<MyPageType>(aPageReference);
This is all good as long as the requested PageData object actually is of a page type that matches the MyPageType class or a subtype of it. But what happens if it isn’t and it’s actual page type doesn’t have a one of it’s properties? Then the above code will still execute without a problem but the code below will throw an exception:
int number = page.SomeRequiredNumberProperty;
This illustrates my first problem with the GetPage<T>() and GetChildren<T>() methods - they are deceiving in that they will always give you what you want, even if it’s wrong. Also, let’s say you are using Page Type Builder and are new to using it. Then it’s really hard to figure out what went wrong. Is it a bug in the page type, or perhaps in Page Type Builder?
Another problem from a Page Type Builder perspective is that when the requested PageData object’s page type matches the requested type Page Type Builder will already have used ShallowCopy (the one without a type parameter) once to replace the returned PageData object and these methods will add some (minor) unnecessary overhead.
Suggested solutions
I would really like to see this problem fixed in the final release of CMS 6 as my guess is that it will be very hard to fix it after it’s release, having then to maintain a stricter backwards compatibility with previous releases in the same major release series. Preferably I would like to see one of two solutions.
Either remove the methods. This would also allow others to add methods with the same signatures as extension methods to DataFactory.
Alternatively change their implementation from using ShallowCopy<T>() to something like the code below, making the methods non-deceiving.
public TPageData GetPage<TPageData>(PageReference pageLink) where TPageData: PageData, new() { return this.GetPage(pageLink) as TPageData; }
I really hope you find one of these two options viable. However, if you don’t then please fire an event before the call to ShallowCopy<T>() in the methods . That way Page Type Builder, and anyone else, can listen to it and throw an exception if the requested PageData object really isn’t of the requested type.
Hopefully, Joel
PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.
Similar articles
- Dependency Injection with Page Type Builder 1.2
- Page Type Builder 0.8 released – Finally!
- EPiAbstractions.Opinionated – A wrapper for EPiServer CMS and Page Type Builder
- Ideas for new features in Page Type Builder 2.0
- A first stab at EPiServer CMS with ASP.NET MVC and Page Type Builder
- Developing with Page Type Builder – Using Interfaces and Advanced Inheritance
- EPiAbstractions.FixtureSupport – Easily create test data for EPiServer CMS
- Developing with Page Type Builder – Getting Started
My book
Want a structured way to learn EPiServer 7 development? Check out my book on Leanpub!
Comments
comments powered by Disqus