smithsson68@gmail.com
Jan 3, 2011
  5169
(0 votes)

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.

Jan 03, 2011

Comments

Please login to comment.
Latest blogs
Caching & Rendering of metadata from the DAM

For the EPiServer.Cms.WelcomeIntegration.UI 1.2.0 release, we have facilitated the ability to cache and render metadata from assets within the DAM....

Matthew Slim | Jun 2, 2023

Conversion Rate Optimization: Maximizing ROI through Data-Driven Decisions

In today's digital landscape, businesses are constantly looking for ways to improve their online presence and drive more conversions. One effective...

JessWade | Jun 1, 2023

Enhance Your Writing with Suggestions

Are you tired of staring at a blank screen, struggling to find the right words? The Epicweb.Optimizely.AIAssistant Addon is here to revolutionize...

Luc Gosso (MVP) | May 31, 2023 | Syndicated blog

Content Graph - Letting GraphQL do all the hard work for you

Background As we have seen before, setting up Content Graph on the CMS side is pretty easy. However, when it comes to the “head” part of the setup,...

Kunal Shetye | May 26, 2023 | Syndicated blog