World is now on Opti ID! Learn more

fredriktjarnberg
Jan 25, 2010
  5727
(0 votes)

Generic overloads of GetPage and GetChildren - To be or not to be?

Joel Abrahamsson put some light on some issues with the newly added generic overloads GetPage and GetChildren on DataFactory as well as the generic overload of ShallowCopy on PageData. These APIs were added mainly to give developers a way to hook in their own PageData implementation in a simple way which was used by the PageTypeTool and was mentioned by Daniel Rodin in his blog post Working with your own PageData types in CMS5 R2 SP2. However, as the use of these methods have been somewhat outdated by the introduction of PageTypeBuilder and as we agree with Joel’s feedback, we are now considering a removal of these APIs by the release of CMS 6.

Our only remaining concern is backward compatibility which is something we struggle to maintain as much as possible (even if we are shipping a new major version).  However our qualified guess (after all we can only guess) is that the adoption of these methods are not that widely spread. If we also take into account that we can create extension methods that replaces all but one of the APIs planned to be cut we think it should be rather safe to get rid of the methods in CMS 6. If you disagree, continue reading.

The signatures that are at stake:

On EPiServer.DataFactory:

public IEnumerable<T> GetChildren<T>(PageReference pageLink)
where T: PageData, new();

public IEnumerable<T> GetChildren<T>(PageReference pageLink, ILanguageSelector selector)
where T: PageData, new();

public T GetPage<T>(PageReference pageLink)
where T: PageData, new();

public T GetPage<T>(PageReference pageLink, ILanguageSelector selector)
where T: PageData, new();

On EPiServer.Core.PageData:

public static T ShallowCopy<T>(PageData copy)
where T: PageData, new();

 

Objections anyone?

We are now interested to hear if there are anyone that strongly disagrees with the suggested change.

Is there anyone out there that uses the APIs listed above?

If yes, would it be sufficient for you to replace the DataFactory changes with equivalent extension methods with the same signature and same semantics?

Please, post a comment here or drop me a mail (fredrik [dot] tjarnberg [at] episerver [dot] com).

Jan 25, 2010

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |