Overview

In Community Server 2008 the spam rules were updated to support dynamic configuration options. This is important because now dynamic configuration code is consistent across new features. For example, the same way that you code for dynamic options in a content fragment (widget) is the same as in spam rules. In the end all of these updates allow for the dynamic options of a spam rule to be easily configured by an administrator.

Previous Structure

In Community Server 2007 spam rules were configurable, but the configuration options were much more limited and the presentation was not as controllable or consistent as it is in Community Server 2008. Previously you would use an ArrayList to store the available settings and when you retrieved these settings you would have to parse them out.

Example: Updating BodyLengthSpamRule

In Community Server 2007 the BodyLengthSpamRule looked like this:

public class BodyLengthSpamRule : BlogSpamRule
{
    private static Guid ruleID = new Guid("843ACA49-6342-4997-A98C-F7A948B32111");
    private static int defaultPoints = 5;
    private static int defaultLength = 10;

    public BodyLengthSpamRule() { }

    public override ArrayList GetAvailableSettings()
    {
         ArrayList settings = new ArrayList();
         settings.Add(new RuleSetting(ruleID, "points", "Points for failure",  
                    defaultPoints.ToString()));

         settings.Add(new RuleSetting(ruleID, "length", "Minimum body length", 
                    defaultLength.ToString()));

         return settings;
    }

    public override int CalculateSpamScore(WeblogPost post, CSPostEventArgs e)
    {
         // Retrieve setting values
         int points = Globals.SafeInt(this.GetSettingValue("points"), defaultPoints);
         int length = Globals.SafeInt(this.GetSettingValue("length"), defaultLength);

         if ((post.Body == null) || (post.Body.Trim().Length < length))
              return points;

         return 0;
    }

    public override string Name
    {
         get { return "Comment Length Blog Spam Rule"; }
    }

    public override string Description
    {
         get { return "Requires comments meet a certain minimum length"; }
    }
 
    public override Guid RuleID
    {
         get { return ruleID; }
    }

}

The updated version of this same rule in Community Server 2008 looks like this:

public class BodyLengthSpamRule : BlogSpamRule
{
    private static Guid ruleID = new Guid("843ACA49-6342-4997-A98C-F7A948B32111");
    private static int defaultPoints = 5;
    private static int defaultLength = 10;

    public BodyLengthSpamRule() { }

    public override PropertyGroup[] GetAvailablePropertyGroups()
    {
        PropertyGroup[] propertyGroups = new PropertyGroup[] { 
             new PropertyGroup("spamOptions", "Spam Settings", 0)
        };

        propertyGroups[0].Properties.Add(new Property("points", "Points for failure",  
                   PropertyType.Int, 0, defaultPoints.ToString()));

        propertyGroups[0].Properties.Add(new Property("length", "Minimum body length", 
                   PropertyType.Int, 1, defaultLength.ToString()));

        return propertyGroups;
    }

    public override int CalculateSpamScore(WeblogPost post, CSPostEventArgs e)
    {
         // Retrieve setting values
         int points = GetIntValue("points", defaultPoints);
         int length = GetIntValue("length", defaultLength);

         if ((post.Body == null) || (post.Body.Trim().Length < length))
             return points;

         return 0;
    }

    public override string Name
    {
         get { return "Comment Length Blog Spam Rule"; }
     }

    public override string Description
    {
         get { return "Requires comments meet a certain minimum length"; }
    }

    public override Guid RuleID
    {
        get { return ruleID; }
    }

}

As you can see there are not many dramatic differences. Also, you should realize that the previous rule will still work in Community Server 2008. The only thing that will not function is being able to configure it in the control panel. This will only work after it is updated to override the GetAvailablePropertyGroups method. Additionally, whenever you do update your previous rule you should be happy to know that the configuration options you had set previously will be available after the update. There is a schema patch that runs during the upgrade process that copies over your spam settings into the new table structure so that when an old spam rule is updated its settings remain intact.

There are really only two things that need to be updated. You should replace the GetAvailableSettings with the GetAvailablePropertyGroups method. This method returns a collection of Telligent.DynamicConfiguration.Components.PropertyGroup objects. These are the same type of propertyGroups that you can find in the theme.config. You can follow the example here to go by or read up on ContentFragments as they too have a similar method that returns the same type of collection.

The second thing that you will need to update is your retrieval of the configuration settings. This is done by simply calling one of the ConfigurationDataBase’s Get[Type]Value methods. In this example the GetIntValue method was called because we were retrieving an integer type value. These methods take two parameters, the first is the identity of the configuration property and the second is a default value in case the property does not exist.

Conclusion

The result of the above changes allows for you, the developer, to collect more configuration options from the user in a much more consistent manner. Whenever the above is rendered to the administrator they will see a form like the one below. Remember, that you really have full control about what is configurable and how those options are presented.

Questions?