This blog post describes how you can use the ItemNamingRules Sitecore Shared Source project to apply the rules engine to control item names using the Sitecore ASP.NET CMS.

This is a repost of http://sitecorejohn.spaces.live.com/blog/cns!960125F1D4A59952!444.entry.

You can use the rules engine to control item names. For example, you may want to enforce character limits in the names of items that correspond to URLs. For more information about the rules engine, see the Rules Engine Cookbook on the Sitecore Developer Network (SDN). For instructions to use the solution described in this post, see the ItemNamingRules documentation. You may also want to read some of my previous posts, including Sitecore Rules Engine and Conditional Rendering, Intercepting Item Updates with Sitecore, and Sitecore Shared Source NewsMover Categorizes News by Date. 

Sitecore supports at least five techniques to control item names:

1. You can use use the InvalidItemNameChars, ItemNameValidation, and MaxItemNameLength settings in web.config to control all item names. See the comment above each setting in web.config for further details. The disadvantage of these settings in this context is that they apply to all items, when you might want rules only for the names of certain items. For example, you might want to allow spaces and other special characters in any item that doesn’t correspond to a URL, or have special naming rules for media.
2. You can use events to intercept actions that name items. One advantage of events is that you can trap all types of user actions and API events that rename items with a single handler. One disadvantage of events in this context is that you specify handlers and parameters in web.config rather than through a user interface. Another disadvantage of events in this context is that it can become cumbersome to configure different rules for different branches of items in the content tree.
3. You can use pipelines to intercept user actions that name items. One advantage of pipelines is that you can interact with the user. Some disadvantages of pipelines in this context are that multiple pipelines can rename and item, but only user actions invoke certain pipelines, and you often have to . Some API calls that name items do not invoke any pipeline.
4. You can use validation, and provide different validation actions for each of the types of rules a name could violate (too long, invalid characters, etc.). The problem with validation in this context is that the user has to navigate to the item and take some actions; it might be nice to fully automate the solution.
5. You can use the rules engine to control item names as described in this post. One advantage of the rules engine is a convenient user interface to define parameters, such as the items to which the naming logic applies.

 

You can continue to use settings, events, pipelines, and validation to control item names. But with 6.1, you can use the rules engine as well.

A rule consists of one or more conditions and one or more actions. When Sitecore evaluates a rule, if the conditions specified in that rule evaluate to true, then Sitecore invokes the actions specified in that rule.

For the condition part of this rule, users might want to apply the rule to one or more specific items, to all items based on a data template, to an item and its descendants, to the descendants of an item, to items matching a query, or to some other collection of items. I assume that the default conditions that ship with the product meet the most common requirements. Two conditions that might be helpful when determining whether or not to rename an item: whether the item has layout details for the default device, and whether the item has layout details for any device.

Regarding the action part of the rule, there would be numerous parameters to specify for a single action. The solution should not force the user to specify parameters they don’t use. But because actions are not aware of each other, the user might have to specify the same parameters to multiple actions. More importantly, the user has to understand the impact of ordering actions. For example, it doesn’t make sense to ensure a minimum name length before removing invalid characters.

I thought about merging certain actions and hard-coding certain parameters, but I generally like a flexible approach. Then I started prototyping, and realized that the flexible approach was more work for both me and any user. So I merged some of the actions (the strong words indicate parameters):

• Replace characters that do not match the regular expression MatchPattern with ReplaceWith, replace sequences of ReplaceWith with a single instance of ReplaceWith, and remove leading and trailing instances of ReplaceWith.
• Ensure a minimum name length by appending characters from DefaultName.
• Ensure that the name is unique and does not exceed MaxLength characters.
• Lowercase.

It’s honestly a coincidence that this simplification eliminates all of the duplicate parameters that I would otherwise have to pass to additional actions. I also sorted the actions so that the user interface displays them in the order in which the user should add them to the rule.

I started out with a base class for actions that rename items.

Then I created classes for each action. 

Before entering any parameters, my rule looks like this:

And after entering parameters:

Now, when I save any item that has layout details for any device, whether I save that item through the UI or through an API call, Sitecore replaces invalid characters with underscores, merges sequences of underscores into a single underscore, trims underscores from the beginning and the end of the item name, appends to the item name to ensure at least seven characters, appends a timestamp to the item name if required to make it unique among its siblings, and ensures that the item name does not exceed 35 characters.

Warning: Like almost any customization, this could have dangerous repercussions, especially if configured incorrectly (for example, by renaming any item in the wrong branch, or in the Core database). Additionally, I didn’t significantly test this before posting, and there are definitely still some issues to think about. For example, you probably don’t want to rename the home item, you don’t want these rules to apply to the __Standard values of data templates (even though they may contain layout details), etc. But enough people ask about this topic that I thought it was time to describe this approach. After some refinement, I will try to make this a shared source project.