Proposed API changes in Visitor Groups (CMS 6 R2)

The EPiServer CMS 6 R2 Beta released just before Christmas has some new functionality called Visitor Groups. You can read more about that here.

Having reviewed the API carefully, we have decided to make a few small (breaking) changes for the next (Beta/RC) release.

CriterionBase

The non generic EPiServer.Personalization.VisitorGroups.CriterionBase class has been replaced by the EPiServer.Personalization.VisitorGroups.ICriterion interface. All criteria must implement this although it is recommended that you use the generic EPiServer.Personalization.VisitorGroups.CriterionBase<T> in your implementations.

CriterionBase<T>

In the CMS 6 R2 Beta, the generic parameter T had to implement IDynamicData and ICloneable.

This has been changed so the generic parameter T now has to implement the new interface EPiServer.Personalization.VisitorGroups.ICriterionModel interface.

ICriterionModel looks like this:

   1:  /// <summary>

   2:  /// Interface for criterion model

   3:  /// </summary>

   4:  public interface ICriterionModel : IDynamicData

   5:  {

   6:      /// <summary>

   7:      /// Create a copy of this criterion model.

   8:      /// </summary>

   9:      /// <remarks>The implementation should have deep clone semantics as appropriate.</remarks>

  10:      /// <returns>The copy of the criterion model.</returns>

  11:      ICriterionModel Copy();

  12:  }

As you will see, the ICriterionModel interface inherits from IDynamicData and also specifies a method for deep copying of the model. We have done this as Microsoft themselves do not recommend the use of ICloneable any more due to its rather cloudy specification about whether a deep or shallow copy should be done. See this article from Brad Abrams for more information.

You don’t have to implement ICriterionModel yourself, you can inherit from the new EPiServer.Personalization.VisitorGroups.CriterionModelBase class. This takes care of the IDynamicData implementation for you but actually declares the Copy method as abstract leaving you to implement this yourself.

Why not have a default implementation marked virtual?

There has been great debate about this internally. OK, but how does the default implementation do a deep copy properly?

We decided to err on the side of safety, by making it abstract it forces you to implement the deep copy property. There is a protected helper method on the class called ShallowCopy which you can call from your Copy implementation. This will help you when you only have values types or as a starting point for a deep copy.

Your feedback on this is as always most welcome and invaluable.