Criterion implementation patterns

To implement a criterion to be used with the personalization concept introduced in CMS6R2 is pretty straightforward. There are however some guidelines to be aware of:

• If you implement ICriterion.Subscribe and in the method set up an event handler for any event then you should implement ICriterion.Unsubscribe as well and in that implementation remove all event handlers that where setup in Subscribe.

The reason for this is to avoid getting “dangling” event handlers which cause both unwanted behavior (in meaning event handlers for unused/old criterions are still called) and “memory leakage” (old criteria instances cannot be garbage collected since they are rooted through the event handler).

The pattern for Subscribe/Unsubscribe is that Subscribe on each used criterion instance is not only called during initialization but also whenever a VisitorGroup containing the criterion is saved. During Save of a VisitorGroup the framework will first call Unsubscribe for all previous existing criteria's on that group. Then new criteria instances will be created for the group and Subscribe will be called on these instances.

• Remember that IsMatch can be called several time during a request.

An obvious consequence of this is that the execution time for the call to IsMatch will affect the time for the web request. You should also avoid taking locks (or at least keep the scope to a minimum) inside the method since that would prevent requests from running in parallel.

If your criteria is dependent on some external resource (for example an external database) then you should take the scenario where the external resource is not accessible into consideration.

The purpose of this post is of course not to scare you from writing your own criteria's (that is something we encourage you to do) but to give you a guideline to successful criterion implementations! :-)